Personal and corporate pathogen-risk assessment with pandemic-bio-surveillance multi pathogen systems

ABSTRACT

Provided is a pandemic-surveillance system configured for obtaining a user profile of a user; obtaining a history of geolocations visited by the user; determining based on the history of geolocations, geolocation-pathogen-risk scores corresponding to the geolocations visited by the user; determining a personal-pathogen-risk score of the user based on the user profile and the geolocation-pathogen-risk scores corresponding to the geolocations visited by the user; and storing the personal-pathogen-risk score in memory

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent claims the benefit of U.S. Provisional Patent Application63/110,860, filed 6 Nov. 2020, titled GEOLOCATION-BASED INFECTION-RISKASSESSMENT AND BEHAVIOR MODIFICATION SYSTEM, and U.S. Provisional PatentApplications 63/055,243, filed 22 Jul. 2020, titled GEOLOCATION-BASEDINFECTION-RISK ASSESSMENT AND BEHAVIOR MODIFICATION SYSTEM. The entirecontent of each afore-listed, earlier-filed application is herebyincorporated by reference for all purposes.

BACKGROUND 1. Field

The present disclosure generally relates to distributed computingapplications and, more particularly, to pandemic-surveillance systems.

2. Description of the Related Art

The need for robust, privacy-friendly pandemic-surveillance systems hasbeen recently highlighted by coronavirus disease 2019 (COVID-19), whichis primarily transmitted between people in close contact, including viahuman movement and airborne transmission. Other pathogens aretransmitted in a similar manner, and it is expected that futurepandemics and other, less-severe outbreaks will give rise to a similarneed, in some cases with other modes of transmission driving spread ofthe pathogen at issue.

SUMMARY

The following is a non-exhaustive listing of some aspects of the presenttechniques. These and other aspects are described in the followingdisclosure.

Some aspects include a process including: obtaining a user profile of auser; obtaining a history of geolocations visited by the user;determining based on the history of geolocations,geolocation-pathogen-risk scores corresponding to the geolocationsvisited by the user; determining a personal-pathogen-risk score of theuser based on the user profile and the geolocation-pathogen-risk scorescorresponding to the geolocations visited by the user; and storing thepersonal-pathogen-risk score in memory.

Some aspects include a tangible, non-transitory, machine-readable mediumstoring instructions that when executed by a data processing apparatuscause the data processing apparatus to perform operations including theabove-mentioned process.

Some aspects include a system, including: one or more processors; andmemory storing instructions that when executed by the processors causethe processors to effectuate operations of the above-mentioned process.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following figures in which like numbers indicate similar oridentical elements:

FIG. 1 is a logical and physical architecture block diagram of acomputing environment in which a pandemic-surveillance system inaccordance with some embodiments may be implemented;

FIG. 2 is a flow chart of an example of a personal-pathogen-risk-scoringprocess that may be executed by the system of FIG. 1;

FIG. 3 is a schematic depicting a data structure for reducing latencywhen querying a geographic information system for pathogen-related-riskrecords pertaining to places-of-interest;

FIG. 4 is a flow chart of an example of ageolocation-pathogen-risk-scoring process that may be executed by thesystem of FIG. 1;

FIG. 5 is a flowchart illustrating an example of a behavior modificationmessaging process in accordance with some embodiments of the presenttechniques;

FIG. 6 illustrates states of a finite state machine consistent with someembodiments of the present techniques;

FIG. 7 illustrates an example of a user interface consistent with someembodiments of the present techniques; and

FIG. 8 illustrates an example of a computing device by which the presenttechniques may be implemented.

While the present techniques are susceptible to various modificationsand alternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit thepresent techniques to the particular form disclosed, but to thecontrary, the intention is to cover all modifications, equivalents, andalternatives falling within the spirit and scope of the presenttechniques as defined by the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

To mitigate the problems described herein, the inventors had to bothinvent solutions and, in some cases just as importantly, recognizeproblems overlooked (or not yet foreseen) by others in the fields ofbiosurveillance, pandemic management, public health, neuropsychology,health analytics, public safety, computer science, and nationalsecurity. Indeed, the inventors wish to emphasize the difficulty ofrecognizing those problems that are nascent and will become much moreapparent in the future should trends in industry continue as theinventors expect. Further, because multiple problems are addressed, itshould be understood that some embodiments are problem-specific, and notall embodiments address every problem with traditional systems describedherein or provide every benefit described herein. That said,improvements that solve various permutations of these problems aredescribed below.

Today, people often have no way of understanding their individual riskof pathogen infection or death during a pandemic based on their personalhealth profile and their movement decisions related to where they live,work, worship, attend school, shop, or travel. Organizations,corporations, and government agencies often have no way of assessingsupply chain risk, the risk of pathogen infection within theirindividual workplace communities (e.g., employees, contractors,customers, students, or visitors), or how to make remote versus onsitework decisions using data science. Public health agencies are lookingfor new insights into effective pandemic practices from new publichealth and biosurveillance digital technologies across the consumer,corporate, non-profit, and federal sectors to drive public health policydecisions.

Many types of software for assessing COVID-19 (or any pathogens andpathogenic) risk leak information that users would prefer to keepprivate, e.g., with certain types of contact tracing nativeapplications. Further, such applications generally only provide aback-ward looking assessment, indicating that a person might have beenexposed in the past. These existing approaches generally do not provideactionable information that users may use to intervene to reduce theirCOVID-19 risk (or other forms of infections). (None of which is tosuggest that systems that produce backward looking assessments or do notprovide actional information are disclaimed.)

The need for the present techniques has been highlighted by recentevents. A single virus can trigger a global pandemic though a singleaction: human movement. COVID-19 was able to infect people in 167countries worldwide in matter of months due to global human movement ofinfected people.

Government solutions have not proven to be ideal. As COVID-19 reachedcertain infection and death thresholds, governments mandated forcedshelter-in-place restrictions. These restrictions did cause infectionand death rate to fall, because human movement was suspended. Given thepremise that a virus spreads through human movement, when human movementis suspended, the virus can no longer infect new people. A good thingfor sure. But with consequences.

This phenomenon left many populations subject to the Teeter TotterDilemma: on one end of a Teeter Totter is a Virus Free World. On theother end is a Robust Global Economy. With a government lockdown, theVirus Free World side of the Teeter Totter moves to the ground and thegoal of reducing infections and deaths is accomplished. However, theother side of the Teeter Totter has now escalated to extreme heightswhere workers lose jobs, renters can't pay rent, parents can't feedchildren, companies lose money or end up bankrupt. To make mattersworse, a pandemic attacked the small business owner and not large,international technology companies. When analysts look at ownership ofmany small businesses, they see underserved communities, communities ofcolor, and people not financially well-off. A pandemic attacks theeconomic foundations of minorities, the poor, the elderly, and theunderserved at disproportionate levels. This is a greatest form ofEconomic Discrimination ever seen by the World.

To make a bad situation worse, the virus does the same when thesecommunities experience viral exposure—experiencing infection and deathrates at 3 to 5 times the level seen in white and wealthy communities.Today, the two sides of the Teeter Totter are in direct conflict witheach other. Presently, governments address the Virus Free World goal byrestricting or banning human movement. When this occurs, lives are savedat the cost of massive economic disruption. Alternatively, governmentsaddress the Robust Global Economy by removing restrictions and banns onhuman movement. When this goal is implemented, economies flourish at thecost of loss of human life and the related mental health issuesexperienced by billions of people. Today, the goals of a Virus FreeWorld and a Robust Global Economy are seemingly at odds. Now a solutionis believed to exists that allows both goals to be jointly achieved.

Some embodiments implement a suite of techniques referred to as“Pandemic Insights Roamwell Solution,” which in come instantiationsremoves this conflict so people can remain mindfully mobile whilereducing infection and death rates. By using Smart Movement technologiesin the form Mobile, SaaS and DaaS solutions—people can remain mobilewhile reducing infection and death rates. Roamwell, in some embodiments,creates dynamic Personal Risk Indexing, dynamic Location Risk Indexingand dynamic Behavior Modification Messaging to guide a person's, acompany's, and a government's movement decisions, all with the singulargoal of reducing infection and death rates. And when Roamwell isdeployed in over 180 countries, including a free mobile app and a freemulti-pathogen personal risk index deployed in various electronic healthrecord systems, the virus driven economic discrimination is expected todecline and hopefully end, allowing people everywhere to prosper,including those most at risk economically.

Embodiments may implement global public health preventive technologiesto reduce infection rates and death rates during pandemics and naturallyoccurring virus cycles, including the following:

-   -   a. MOBILE APPLICATION: EMPOWERING HUMAN MOBILITY DECISIONS        -   i. The Mobile App, in some embodiments, includes three            features: Personal Risk Index, Location Risk Indexes for any            location in the world (or a subset thereof), and Behavior            Modification Suggestions based on a User's movement            patterns. Each of these three features may include a dynamic            capability and may be interactive. Based on a User's            location movement and behavior patterns, each of these            features may change with the unified goal of reducing a            User's risk of virus exposure and infection by changing            their movement behavior.        -   ii. In some embodiments, the Mobile App predicts the daily            risk of infection exposure for any person visiting or            working in any home, building, facility, or unique location            in the world. The Mobile App may create a location-based            risk index for each place the User visits. With this            service, Users are expected to be able to make intelligent,            fact-based movement decisions during a pandemic in order to            reduce their risk of infection and death, and the spread of            COVID-19 (or any other virus or pathogen). Risk Index            forecasts may also be created for any location a User or            family member may visit in the future using various public            pandemic forecast models.        -   iii. Based on a User's individual movement patterns (e.g.,            number of places visited, time spent at each location, the            arrival time for each location, and risk index for each of            the locations visited), the Mobile App may deliver behavior            modification suggestions to each User. Depending on whether            the User follows the behavior modification suggestions, in            some embodiments, the Mobile App delivers changing            suggestions designed to increase the likelihood of modifying            the Users behavior to lower-risk movement patterns.    -   b. SOFTWARE-AS-A-SERVICE: EMPOWERING ECONOMIC STABILITY AND        WORKPLACE SAFETY DURING PANDEMICS        -   i. In some embodiments, the SaaS solution reduces a) the            risk of infection for each facility based on where the            facility employees live and b) the risk of end-to-end supply            chain disruptions during pandemics. Some embodiments of the            SaaS solution are designed for corporations, government            agencies, and non-profits so they can analyze facility,            employee, customer, and supply chain exposure risks. SaaS,            in some cases, integrates demographic and virus data with            anonymized employee HR data to create a Facility Risk Index            and Workforce Risk Pods based on the home locations and            demographics for 100% of a facility's local workplace            communities (e.g., employees, contractors, customers,            students or visitors). SaaS customers can, in some cases,            avoid organization-wide workforce strategies and supply            chain decisions that ignore site location-risk indexes.            Government agencies can, in some cases, help keep employees            and contractors healthy by understanding the risks a) in and            around facilities and b) where their personnel live and            move.        -   ii. Some embodiments of the SaaS solution also create and            end-to-end supply chain risk assessment feature. Companies            importing parts and components for manufactured goods can,            in some cases, assess vendor supply risk based on the            location of each vendor and the related shipping logistics.            Based on the daily supply chain risk assessment, companies            can, in some cases, make decisions to reallocate purchases            to vendors in lower risk regions or seek new vendors in            regions with reduce pathogen exposure. Additionally,            companies can, in some cases, assess the distribution of            finished goods to all points of sale worldwide. Outbound            routes can, in some cases, be altered based on the supply            chain pathogen assessment to provide the lowest pathogen            exposure risk.    -   c. DATA-AS-A-SERVICE: A PUBLIC HEALTH POLICY AND MOBILE SAAS        INTEGRATION SOLUTIONS        -   i. In some embodiments, the DaaS Pathogen Data Lake delivers            daily, hyper-local building level risk indexes that equip            public health policymakers with actionable insights and            trends for any pathogen. From the first day a pathogen is            reported, in some use cases, the SaaS instances tracks and            visualizes the hyper-local risk levels and movement            patterns. Policymakers can, in some cases, leverage these            insights to enhance and improve policy decisions. Further,            policymakers may receive insights regarding the Mobile and            SaaS applications in countries where deployment to            understand how pathogen infection rates are being impacted            via the applications. These results can be compared to            countries not using the applications to identify the            potential for reduce infection rates via new public health            policy decisions and the adoption of Mobile, SaaS, and DaaS            applications with demonstrated and known public health            benefits.    -   ii. In some embodiments, the DaaS 3rd Party Integrator allows        any third-party application and website to access the DaaS        Pathogen Data Lake and its hyper-local risk index end points and        display that information within the solution based on a logical        trigger (e.g., destination arrival or system query). The User        may be presented with risk indexes in the digital asset that        informs them of the virus infection risk for a location. Third        party digital asset integration Use Cases may include: mapping        and navigation—to reduce pathogen exposure risk during        automotive trips (e.g., On-star™, Google Maps™, Waze™, etc.),        travel planning—see a city's or travel route risk score before a        user travels (e.g., American Airlines™, Crystal Cruise Lines™,        Kayak.com™, etc.), lodging—to see the future risk score for a        rental property or hotel prior to booking (e.g., Marriott™,        Hilton™, Airbnb™, VRBO™, etc.), education—university        administrators can see the risk index for all university        students (based on the students home address) prior to the start        of classes to develop safe campus movement strategies, and        transportation—a management tool for fleet assets to reduce        exposure risks (e.g., FedEx™, UPS™, USPS, etc.) or ride share        trips (e.g., Uber™, Lift™, etc.).

FIG. 1 is a physical and logical architecture block diagram illustratingan example of a computing environment 10 in which apathogen-surveillance server system 12 may cooperate with mobilecomputing devices 14 to surveilled a plurality of different pathogensand variants thereof. As explained in greater detail below, theillustrated distributed computing architecture may be operative todetermine personal pathogen-risk scores of individual users; determinegeolocation pathogen-risk scores of various places-of-interest; generateand customize behavior modification messaging for individuals to reducetheir pathogen risk; and generate and customize behavior modificationmessaging for organizations to reduce the organizations' collectivepathogen risk linked to the movement of its employees, contractors,customers, and manufacturing and distribution assets, and all enterprisesupply chain movements worldwide. In some embodiments, these featuresmay be implemented with privacy-safe movement transaction processing toassess pandemic risk, in some cases with information about variousplaces-of-interest enriched with self-reported attributes ofplaces-of-interest used to enhance or suppress corresponding risk scoresof those places. It should be emphasized that a variety of independentlyuseful inventive techniques are described herein. As such, it should notbe assumed that all embodiments deploy the full suite of innovationsdescribed, as some embodiments may only use a subset of theseinnovations. Thus, simply because a technique is described as affordingsome advantage or addressing some problem, it should not be assumed thatembodiments are limited to approaches that afford that advantage orsolve that problem.

Some embodiments include a server system, like system 12, (e.g., asingle server or a collection of servers, like in a micro-servicesarchitecture) that ingests location-indexed information relevant toassessing COVID-19 risk or risk from other pathogens, such as anypathogen (bacterium, virus, or other microorganisms that may causedisease), whether naturally occurring in nature or intentionallymanufactured by people, that may create a pandemic. In some cases,various third-party APIs hosted on other server systems 18 may beinterrogated for such information.

Some embodiments include a client computing device, like devices 14, 20,and 24 (e.g., physically remote from the server system 12) upon whichusers interact with the server system via a network, like the Internet.Examples include a desktop computer, laptop computer, mobile phone,automated teller machines, electronic public billboards, and the like.Interaction may be mediated by a web browser or a native applicationexecuting on the client computing device. In some cases, the serversystem hosts a geographic information system 84 in which attributesrelevant to assessing COVID-19 (or other pathogen) risk are indexed togeographic places, e.g., coordinates, grid squares (or other regular orirregular tilings), places-of-interest (such as those bounded by apolygon with vertices expressed by latitude and longitude coordinates),metropolitan areas, voting districts, census blocks, ZIP codes, and thelike). Examples of places-of-interest in include public places likeairports, train stations, port authorities, courts, indoor places, likestores, restaurants, gyms, hotels, office buildings, residentialproperties, and local and national parks, and other physical and openplaces.

In some cases, information relevant to COVID-19 (or other pathogen) riskof geographic places is aggregated and analyzed by a server-sideapplication executing on the server system. Examples of such analysesare described in the more expansive description of the figures thatfollows this overview.

In some cases, a native application 58, e.g., executing in thebackground of mobile user computing devices 14, interfaces with theserver system 12 to obtain information about risks of places beingvisited. The native application 58 may interact with a geolocationframework or library of the client device's operating system (e.g., acorelocation framework on iOS™ or CLLocationManager class in Android™)to register to obtain events indicative of geolocation or changesthereof, e.g., traversing a geofence corresponding to aplace-of-interest for which risk data is available from the serversystem 12, detecting a dwell, or detecting a change in position ofgreater than a threshold distance that warrants re-assessment. In somecases, the native application 58 (or a corresponding web applicationaccessed via a browser) may locally compute aggregate measures ofpersonal COVID-19 (or other pathogen) risk based on a sequence ofvisited places, or some embodiments may compute these values with theserver system 12.

In some cases, information about COVID-19 (or other pathogen) risk ofplaces may be aggregated across visits reported by a population ofuser-computing devices in a privacy-friendly way. For example, someembodiments may implement differential privacy approaches by which noise(e.g., by adding or subtracting random values from client-side metrics)is injected client-side by devices 14 into information reported to theserver system 12, thereby frustrating attempts to de-anonymize theclient device, while still permitting calculation of accurate populationstatistics (e.g., of a population that has visited a place) pertainingto COVID-19 (or other pathogen) risk by server system 12.

In some cases, to reduce battery consumption, geofence traversal isdetermined client-side by maintaining and updating a list of localgeofences (e.g., within a threshold distance of a current location)relevant to the user's current location, along with COVID-19 (or otherpathogen) risk related attributes of those places. Or some embodimentsdetect geofence traversal server-side, by reporting geolocation of theuser-device to the server, which then cross-references against ageographic information system to retrieve such attributes.

In some cases, notifications intended to modify user behavior arepresented on mobile devices 14 by native application 58 or via SMSmessages or automated calls. Some embodiments may sense, after suchnotifications, whether the user complied with the suggestion and reportto the server system the result. In some cases, the server system maymaintain a list of different phrasings of suggestions and modify whichare presented based on reported efficacy, e.g., with automated A/Btesting. In some cases, the server system may train a machine learningmodel to predict efficacy based on various demographic and psychographicattributes of users and historical reported efficacy. The model may beused after training to select which notifications to present todifferent users.

In some embodiments, end users' computing devices may interface with theserver system via web browsers, native applications, app clips, instantapps, and the like, executing on the client devices 14, 20, and 24.

In some embodiments, the server system 12 supports on-demand dynamicactivation of cloud-based software components, e.g., with an elasticallyscalable set of lambdas, containers, virtual machines, or the likeimplementing various functional components described herein.Orchestration may be implemented with Kubernetes™, Apache Mesos™, or thelike. Some embodiments may be implemented with AWS Lambdas™, whichprovides a computing environment to execute code without the need toprovision or manage servers. Services may be by lambda's as respectivefunctions, instances of which may be dynamically provisioned in responseto event notifications received from an event notification generator.

In some embodiments, the server system may provide on-demand access byinternal users, external users (e.g., customers, service partners), anddevelopers, such as via infrastructure-as-a-service (IaaS),platform-as-a-service (PaaS), and software-as-a-service (SaaS)architectures, which in some cases, may be provided from a governedfederation of internal (e.g., private cloud) and external cloud (e.g.,commercial cloud) service providers. Some such embodiments allow forrapid and dynamic deployment and scaling of cloud-computing services. Insome embodiments, a virtual appliance used to create a virtual machinewithin, for example, the Amazon Elastic Compute Cloud (EC2)™. In someembodiments, the server system may use Amazon Web Services™, Azure™,Google Cloud Platform™, or the like, for cloud-based components. In someembodiments, storage may be implemented with Amazon's Simple StorageService (S3)™, Redshift™, Google Cloud Storage™, or the like.

In some embodiments, server system 12 may be implemented with tools likeGluon™, Keras™, pytorch™, tensorflow™, and the like, to prototype,build, and train machine-learning models, e.g., deep learning models,random forest models, deep reinforcement learning models, and the like.Supervised, semi-unsupervised, self-supervised, or unsupervised modelsmay be used. In some cases, a collection of such models may be combinedin an ensemble or pipeline.

In some embodiments, Amazon Simple Workflow (SWF)™, Celery™, Airflow™,or the like, may be used to maintain the execution state of workflows,tracks workflow versions and keeps a history of past workflowexecutions.

In some embodiments, AWS Data Pipeline™, Azure Data Factory™, SnapLogicIntelligent Integration Platform™, or the like, may be used to automatemoving and transformation of data.

In some embodiments, Amazon Elastic Map-Reduce (EMR)™, Hadoop™, Spark™,Flink™ or the like may be used to analyze data concurrently, in afault-tolerant, resilient fashion.

In some embodiments, Amazon's Simple Notification Service (SNS)™, ApacheCamel™, or the like may push messages from software applications tosubscribing endpoints and clients, and may be used as monitoring andmanagement system.

In some embodiments, a cloud computing resource management applicationmay provide one or more interfaces for configuring data sources fromwhich performance or relationship data may be collected. Each datasource may be a source defined by a particular cloud computing serviceor may be a source external to any cloud computing service.

In some embodiments, a cloud computing management application may beconfigured to generate topology map, bioinformatic or computationalbiology visualizations of resources based on data collected and storedby a data collection module. A topology map, bioinformatics orcomputational biology visualization may include a geolocation-baseddisplay of a set of nodes, each representing one or more cloud computingresources, and edges, each representing a relationship between two ormore cloud computing resources.

Embodiments are expected to address various technical issues describedbelow that arise at scale. In some embodiments, the computingenvironment 10 is geographically distributed, for example over theUnited States, North America, or the world. In some embodiments,components like the pathogen-surveillance server system 12 may bereplicated with different instances serving and storing data aboutdifferent geographic areas corresponding to the territory of varioussovereign entities with an interest in how data is handled in theirterritory, in some cases without data being moved between territoriesfor some jurisdictions. In FIG. 1, three mobile computing device 14 areshown by way of example, but it is expected that commercial deploymentswill involve substantially more, for example, more than 1 million, morethan 10 million, more than 100 million, or more than 1 billion computingdevices 14 corresponding to corresponding numbers of members of thepublic participating in the computing environment 10. Similarly, theother illustrated components may be replicated with multiple instancescorresponding to other examples of the various described components,with the depicted examples merely serving to show one example of thetype of systems with which the mobile computing devices 14 and serversystem 12 may interface.

In some embodiments, the computing environment 10 may further include anelectronic medical record system 16, various public (or private)application program interface servers 18, computing devices of partiesauthenticated to supply information about places-of-interest 20,administrator computing devices 22, and healthcare worker computingdevices 24. It is expected that commercial embodiments will interfacewith multiple instances of each of these components in some deploymentsconsistent with the present techniques. In some embodiments, theillustrated components may communicate via the Internet 26 and variousother intermediary networks, like cellular networks, wireless areanetworks, personal area networks, local area networks, and the like.

In some embodiments, the mobile computing devices 14 and other describedcomputing devices may include the components of the computing devicedescribed below with reference to the last figure. Some embodiments ofmobile computing devices 14 may include various software and hardwarecomponents by which some aspects of the present techniques may beimplemented. In some embodiments, the mobile computing devices 14 mayinclude memory 30 (which may include persistent and dynamic memory), oneor more processors 32 (such as a central processing unit (CPU), andvarious hardware accelerators, like graphics processing units, machinelearning accelerators, and the like), a cellular radio 34 (for example abaseband processor, MAC, PHY, and antenna for a 3G, 4G, or 5G, or latergeneration cellular network), a Wi-Fi™ radio (again having a networkinterface with a MAC, PHY, and antenna), a Bluetooth™ radio 38, a nearfield communication radio 40, a global positioning system sensor 42 (orother satellite navigation signals sensor, like GLONASS or Galileosensors), and an ultrawideband radio 44. In some embodiments, components34, 36, 38, 40, and 44 may both transmit and receive signals accordingto their respective protocols and allocated frequencies.

In some embodiments, the mobile computing devices 14 may further includea trusted execution environment 46 having a separate processor 48 (likea microcontroller or central processing unit) and memory 50. In someembodiments, the trusted execution environment 46 may be in a physicallydistinct region of a system-on-a-chip from the components 30 and 32 oron a separate chip, in some cases with the memory 50 being in adifferent physical address space the memory 30, for example, on adifferent memory bus or in a different range of addresses thereon forwhich the processor 32 or memory controller thereof is not configured toread or write directly to or from. The term “trusted” in this context isnot indefinite in that it requires some measure of subjective trust, butrather refers to a term of art in which a class of executionenvironments are typically identified in the field and distinguishedfrom untrusted computing environments on the same device. In someembodiments, the trusted execution environment 46 may store relativelysensitive data, like encryption keys for decrypting data in memory 30 orin memory 50, private cryptographic keys of asymmetric encryption keypairs used for authenticating a user or digitally signing communicationsassociated with a corresponding public cryptographic key or decryptingcommunications encrypted with the corresponding public cryptographickey. In some cases, a public key of a cryptographic key pair (e.g.,generated and exchanged with Diffie-Helman, RSA, ElGamal, ellipticcurve, or various other asymmetric or hybrid cryptographic protocols)may include a pubic key by which a user is identified by and to system12 and a private key by which the user is authenticated (in some cases,without revealing the private key to system 12). In some embodiments,the trusted execution environment 46 may communicate with the processor32 via a relatively narrow channel, for example, via interrupts or othermessaging protocols that have a relatively low attack surface.

In some embodiments, the mobile computing devices 14 further include abattery 52 that powers operation of the device and a camera 54. Each ofthe illustrated components may be in communication with processor 32,which may coordinate their operations. Some embodiments may furtherinclude an inertial measurement unit (IMU) having various accelerometersand gyroscopes (like a six axis IMU) and a magnetometer collectivelyused for dead reconning indoor positioning when GPS signals or cellularor WiFi™ triangulation are not available due to signal attenuation by asurrounding structure.

In some embodiments, the processor 32 may execute an operating system 56(which in some cases is not executed by the trusted executionenvironment 46, which may have a separate operating system or mayfunction without an operating system, for instance being implemented asa microcontroller or with a unikernel). The operating system 56 mayprovide an environment in which various services are exposed to a nativeapplication 58 configured to communicate with the server system 12. Insome embodiments, the services include a geolocation framework 60. Insome embodiments, the native application 58 may register with theoperating system to receive events detected by the geolocation framework60, for example, registering a callback function that, when called bythe geolocation framework 60, causes the native application 58 twoexecute various responsive routines, like event handers that supplementgeolocation histories in user profiles and request updates to riskscores.

In some embodiments, the geolocation framework 60 may be configured toemit events to the native application 58 responsive to various criteriaspecified by the native application 58, for example, the user movingmore than a threshold amount, a change in a detected instance of theuser dwelling within a location (for example being within a specifiedarea for longer than a threshold duration), the user changing locationby an amount sufficient to modify base stations or cellular towerscommunicating with radios 36 or 34, the user moving by more than athreshold amount as detected by an inertial measurement unit of themobile computing device 14, or the like. Offloading detection of theseevents to the framework is expected to reduce battery and bandwidthconsumption, as the framework may provide similar services for a varietyof native applications, which is less resource intensive than havingeach application do the same.

In some cases, it may be less power intensive to obtain coarsegeolocation measurements (like which cellular tower is proximate) thanfine-grained geolocation measurements (like with GPS). Some embodimentsof application 58 may selectively switch the framework 60 between whichtype of location measurement mode is used to preserve the battery 52.For instance, coarse geolocation measurements may be used when thenative application detects that the user is moving faster than athreshold speed, like in a car, while fine-grained measurements may beused when the user moves slower and is in a crowded wirelessenvironment, like in a densely populated area.

In some embodiments, the geolocation framework 60 may further monitorwhether the user's geolocation has crossed a boundary of a geo-fenceregistered by the native application 58 with the geolocation framework60, for example, at the behest of the server system 12 upon the serversystem 12 supplying a set of local, potentially relevant geo-fences tothe native application 58 upon being queried for such geo-fences, forinstance, after the native application 58 receives a signal indicatingthe user has moved by more than a threshold amount, or geofencescorresponding to a predicted future location determined with thetechniques discussed below. In some embodiments, geo-fence traversal maybe detected remotely by the server system 12 or some other third-partyservice, for its instance responsive to the native application 58emitting a signal indicative of a user's new geolocation. In some cases,places-of-interest with higher than a threshold pathogen risk may begeofenced, detecting traversal of which may cause the native application58 to present a warning to the user.

In some embodiments, the native application 58 may further register toreceive updates from the Bluetooth radio 38, NFC radio 40, ultrawidebandradio 44, cellular radio 34, Wi-Fi™ radio 36, and an inertialmeasurement unit of device 14. In some embodiments, for example, indoorpositioning may be sensed with the ultrawideband radio 44, for instanceresponsive to ultrawideband signals of various ultrawidebandtransmitters positioned in an indoor space, or responsive to identifiersof Bluetooth™ beacons received by the Bluetooth radio 38. Similarly,relatively precise positioning may be sensed with the near fieldcommunication device 40, for instance, responsive to the user placingthe device within some threshold distance, like less than a meter of atransmitter in a point-of-sale terminal or NFC access panel of anelectronic door lock.

In some embodiments, the native application 58 may be downloaded andinstalled on the mobile computing device 14 from a remote repository ofnative applications, such as one hosted by a provider of the operatingsystem 56, like the Apple App Store™ or Google Play Store™. In someembodiments, the native application 58 may be provided by the sameentity that provides the server system 12, and that entity may co-host acopy of the native application code in the same code repository as onehosting the code of the system 12. In some embodiments, uponinstallation, a user may register an existing account or create a newaccount with the server system 12, which may include populating a userprofile with various physiological attributes (including medicalconditions), psychographic attributes (e.g., values, desires, goals,interests, and lifestyle choices), and demographic attributes (like age,weight, gender, medical issues, and the like), and pathogen location andbehavior risk avoidance preferences, examples of all of which aredescribed in the provisional applications incorporated by reference bythis filing.

In some embodiments, some or all of the data of the user profile may bestored exclusively on the user's mobile computing device 14, forinstance in encrypted memory with the decryption key (for example, asymmetric encryption key or asymmetric encryption key) stored in memory50, or some or all of the data may be stored in the server system 12. Insome embodiments, less sensitive data may be stored in the server system12 (like ZIP code), with more sensitive data (like full address) storedexclusively on the mobile devices 14. In some embodiments, the userprofile data may be encrypted while in flight and at rest, and the dataof the user's profile may be provided in anonymized form to the extentis provided to the server system 12. User profiles may include anysubset of the various types of data described as being in the userprofiles herein, and user profiles need not include all such fields toqualify as such, which is not to suggest that any other feature is notalso amenable to variation.

In some embodiments, the data provided to the server system 12, to theextent any user profile data is provided, may be further protected withdifferential privacy techniques. In some embodiments, attributes of theuser profile may be modified with a respective value randomly (e.g.,pseudo-randomly) selected from a corresponding distribution for theattribute, like a Gaussian distribution from which a value is selectedto inject noise by adding the value to the value of the user's profile.In some embodiments, the attribute-specific distribution may be selectedsuch that a measure of central tendency of that distribution (like amean, median, or mode) matches the unmodified value in the user profile.In some embodiments, this technique may allow the server system 12 toaccurately compute population-level statistics, without the serversystem 12 having access to the unmodified values in user profilesthrough application of the central limit theorem.

In some embodiments, the native application 58 may execute steps of thevarious processes described below with reference to flowcharts and datamodels. In some embodiments, the native application may further registerto receive push notifications from the server system 12, for instancevia the Firebase Messaging Service™ or Apple Push Notification service™.

In some embodiments, when the user is not interacting, the nativeapplication 58 may execute as a background process of the mobilecomputing device 14, for instance, in a low-power mode, ready to receiveand process updates as the user moves through various geographic areasand visits various places-of-interest. Some embodiments, the nativeapplication 58 may further have access to various other services fromwhich future movements may be inferred, for example, a calendar of theuser (either hosted on the mobile device 14 or in a remote server) and anavigation application (like a mapping application) in which the userrequests and obtains routing information by which the user navigates tovarious geographic places specified by the user. In some embodiments,the native application 58 may obtain and process various geolocations tobe potentially visited to make the types of predictions described below.Examples include determining that the calendar or requested route in amapping application indicates the user intends to travel to a identifiedplace-of-interest in the future, querying from the server system 12 arisk score of that place-of-interest, determining whether that riskscore exceeds a threshold, and in response to determining that the riskscore exceeds a threshold, causing a user interface to be presented tothe user indicating a warning and in some cases suggesting analternative to the problematic place-of-interest, such as a anotherbusiness providing goods or services in the same category that isgeographically proximate (for instance, the closest or within somethreshold distance or travel time of the user's current location orpredicted future location) or alternatively or additionally, suggestingan entirely new route with lower risk factors. In some cases, futurevisits to places-of-interest may be inferred from a person's historicalvisits, e.g., by training a hidden Markov model (or other dynamicBayesian network), recurrent neural network, or transformer architectureon a person's geolocation history and querying the model for predictionsof future visits given a recent (within a threshold number of places oramount of time) set of places visited or given a day of the week.

Reference herein to various scores or probabilities being compared tothresholds should be read broadly as encompassing both scenarios whereincreasing score has one semantic value and scenarios where describingthe score has the same sematic value. For instance, reference to adetermination that a score exceeds a threshold should also be read asreferencing a scenario where the inverse or negation of that score isless than a threshold. Similar principles apply to probabilities beingcompared to thresholds, e.g., determining that the probability of anevent occurring exceeds a threshold is equivalent to determining thatthe probability of the event not occurring is less than the threshold.

In another example, the native application 58 may register to receiveinformation about social networks in which the user is a member, forinstance from Facebook™, LinkedIn™, Instagram™, workplace organizationcharts, or the like, provided that the user authorizes such access. Insome embodiments, the user's social network may be interrogated toidentify other members of the public adjacent the user in the socialgraph or within some threshold distance of the user in a social graph,for instance less than two less than three or less than four links in asocial graph. These other people may be identified (e.g., pseudonymouslyor anonymously) and associated with the user in the user profile, insome cases with those other members of the public being associated withtheir own unique identifiers within the pathogen-surveillancedistributed application implemented with the computing environment 10,of which the user of the computing device 14 may have one as well. Insome embodiments, these identifiers may be unique to individuals,persistent, but not contain any personally identifiable information. Orin some cases, these identifiers may mutate over time, in some cases ina deterministic way and in some cases in a nondeterministic way, to makeit harder to track the users over time to protect user privacy. In someembodiments, a user may specify their social network manually byselecting from their contacts or other users having profiles within thepathogen-surveillance distributed application being described. In somecases, the resulting records may be stored in the user's profile.

Interaction with EMR records, to the extent implemented in someembodiments, is done in a privacy-sensitive, HIPPA-compliant manner,with user consent. In some embodiments, functionality of the nativeapplication 58 or system 12 may be integrated into an electronic medicalrecord system, or the native application 58 or server system 12 mayfurther authenticate itself to the electronic medical record system 16and access the user's medical records, provided that the user authorizessuch access. In some embodiments, these medical records may supplementthe self-reported medical attributes of the user. In some embodiments,the native application 58 may further have write access to such recordsin the electronic medical record 16 or the server system 12 may havewrite access, for instance with the ability to write a personal riskscore or data indicative of patterns of behavior relevant to diagnosingand otherwise assisting the user. Some embodiments may interface with adiverse set of electronic medical record systems 16, e.g., havingdifferent APIs and data formats. In some cases, an EMR system may causemessages to be sent that prompt users to install the native applicationto view context to a risk-related message or the message itself, whichmay tend to increase the install base.

In some embodiments, the native application 58 or server system 12 mayfurther register to receive data from various wearable and non-wearablebiometric monitoring devices of the user, like smart watches with pulseoximeters, movement trackers, heart rate sensors, sleep sensors, and thelike, or smart scales, blood monitoring devices, blood sugar levelsensors, blood pressure sensors, and the like. In some embodiments, uponbeing authorized by the user, such data may be processed by the nativeapplication 58 or stored in the user profile to further augment thepersonal risk assessment.

Details of examples of specific risk score calculations based upon thetypes of data described as accessible to the native application 58 aredescribed with greater detail below with reference to the variousflowcharts.

In some embodiments, the pathogen-surveillance server system 12 mayexecute various processes like those described below with reference toflowcharts to surveil the spread of various pathogens and variantsthereof and compute scores indicative of risk for those pathogensattributable to individuals, organizations, and places-of-interest.Further, some embodiments may effectuate various types of messagingdescribed below to mitigate that risk, in some embodiments usingtechniques described below that afford various privacy protections andbenefit from information supplied by parties operating or with intimateknowledge of places-of-interest. In some embodiments, the server system12 may include an application program interface server 70, a web server72, a controller 74, an anonymized user profile repository 76, a cacheserver 78, an orchestrator 80, a real-time stream processing computecluster 82, and a geographic information system 84. In some embodiments,the illustrated components of the server system 12 may be implemented ina monolithic architecture on a single computing device or as adistributed architecture, for instance, as a microservices architecturewith different instances of each component or various servicesconstituting the components implemented as virtual machines, containers,lambda functions, unikernels, or standalone computing devicesimplemented in a private, public, or hybrid cloud computing physicalarchitecture.

In some embodiments, the servers 70 and 72 may by bound to a networksocket to receive network communications addressed to a correspondingport number to which they are bound. In some embodiments, the servers 70and 72 may be nonblocking web servers, for instance implemented withpromises or deferred's, operative to service a relatively large numberof concurrent sessions, such as more than 100, more than 1000, or morethan 10,000. In some embodiments, network communications may include asession identifier by which communications may be associated withprevious communications in the same session. In some embodiments, astateless communication protocol may be used, and some embodiments mayimplement, for example, a representational state transfer, or REST,protocol.

In some embodiments, communications via the servers 70 and 72 arecoordinated by the controller 74, which may coordinate the operation ofthe other components of the server system 12. In some embodiments, thecontroller 74 includes a view generator operative to generate userinterfaces (e.g., data to populate UI templates or HTML, CSS, andJavaScript™ directly) for obtaining information and presenting outputsto users. In some embodiments, the controller 74 executes the variousprocesses described below with reference to flowcharts attributable tothe server system 12 by coordinating with the other illustratedcomponents.

In some embodiments, the anonymized user profiles 76 may be stored inthe server system 12, though it should be emphasized that someembodiments may leave this information exclusively on the mobilecomputing devices 14 to further enhance privacy, which is not to suggestthat any other feature is not also amenable to variation. In someembodiments, these anonymized user profiles 76 are stored in encryptedform and associated with identifiers that distinguish among users of theserver system 12 without correlating with personally identifiableinformation of the user. In some embodiments, the user profiles 76 aredifferent from user profile stored on the mobile computing devices 14,for instance, the user profiles in the repository 76 may have reducedgranularity (storing ZIP code rather than street address, or decade ofage rather than exact age), the user profiles in the repository 76 mayhave been modified with differential privacy techniques that injectnoise, or the user profiles in the repository 76 may have a subset ofthe data stored in the user profiles on the mobile computing devices 14,each to further enhance privacy. In some embodiments, the illustratedrepository is a relational database or a noSQL database, such as akey-value store or document-based database, for instance based upon XMLor JSON documents.

In some embodiments, the cache server 78 includes an instance of Redis™or Memcached™ to facilitate relatively fast responses to request to theserver 70 and 72 implicating recently accessed data. In someembodiments, the recently accessed data may be indexed with a hash valuebased upon the content of the data or an identifier of the data, suchthat the recently accessed data may be relatively quickly indexed into,for instance, via a key-value store where keys correspond to the hashvalues, like a hash table. In some embodiments, the cache server 78 may,for some periods of time maintain, data that is inconsistent with themore authoritative records in the user profile 76, geographicinformation system 84, or other repositories of the server system 12,until the corresponding caches are invalidated or updated with newvalues.

In some embodiments, the server system 12 includes anatural-language-text generation model 79 that implements behavior andorganizational modification messaging based upon pandemic risk scoring,as described in greater detail below, including in passages withreference to FIG. 5 and FIG. 6.

In some embodiments, the orchestrator 80 may be operative to orchestrateoperation of various components by which the pathogen-surveillanceserver system 12 is implemented. In some embodiments, this may includeelastically scaling, managing, and configuring compute resourcesavailable based upon demand. Some embodiments may dynamicallyinstantiate additional virtual machines, containers, unikernels, or thelike responsive to need and destroy those instances when the needpasses. Some embodiments may include components by which a privatedomain name system is implemented to facilitate communication among themanaged components, by mapping Internet Protocol addresses of thosecomponents to domain names within a private domain name space of theserver system 12. In some embodiments, the orchestrator 80 may beimplemented with Kubernetes™ or Docker™, for example.

Some embodiments may further include a real-time stream processingcompute cluster 82. Examples include compute clusters implemented withApache Spark™, Flink™, or the like. In some embodiments, data may bestored in resilient distributed datasets, which may include a read-onlymultiset of data items. These data items may be distributed among acluster of computing devices in a manner that affords fault tolerance inthe event that one of those computing devices fail, e.g., withredundancy. The data items may form a distributed shared memory thataffords more flexibility than non-shared approaches like in some formsof MapReduce, which is not to suggest that use of MapReduce ornon-shared approaches is disclaimed. In some cases, the analysis may beiterative, in the sense that the same data item may be processedmultiple times, in some cases responsive to branching logic, and in somecases, producing transformed data items, which is expected to affordlower latency than some MapReduce implementations. In some cases, thecompute cluster may be implemented with a cluster manager anddistributed storage system, and the system may be configured to performstreaming analytics by performing transformations on mini-batches ofdata, in some cases implementing a lambda architecture. Or someembodiments may respond to events (e.g., those implemented with ApacheStorm, as applied in Flink™), rather than mini-batches, to reducelatency arising from mini-batch durations. Some embodiments mayimplement structured streaming with datasets in continuous processing.

Some embodiments may further include a geographic information system 84.The term “geographic information system” is a term of art used to referto a particular class of data repositories configured to storeinformation about geographic places. In some embodiments, the geographicinformation system 84 may facilitate relatively fast access toinformation about designated places in queries with a data modeldescribed below with reference to FIG. 3. Some embodiments may maintainrecords of places-of-interest, like businesses, parks, governmentoffices, schools, golf courses, municipalities, cities, counties,states, and countries, each of which may be represented by boundingpolygons having vertices expressed as latitude and longitudecoordinates, each having a unique identifier and a record indicatingattributes of the corresponding place-of-interest. Examples of suchattributes may include location risk scores and location attributesrelative thereto described below, along with names of the place,categories of the place in an ontology of places, likebusiness→restaurant→Italian food.

In some embodiments, the geographic information system 84 may store suchrecords for more than 10,000, more than 100,000, more than 1 million, ormore than 10 million places-of-interest in a geographic area. Someembodiments may be configured to respond to a query specifying a singlelat-long coordinate by returning one or more places-of-interestencompassing that coordinate. Servicing such queries may be relativelyslow with some traditional approaches that require comparing thatlat-long coordinate to every polygon in the entire database to determinewhich polygons include the lat-long coordinate (some of which may beoverlapping polygons). Point-in-polygon algorithms, like the windingalgorithm, or the ray-tracing algorithm, are relatively computationallyexpensive, and replicating them, for instance, 10 million times forevery place-of-interest to determine which places-of-interest includethat point is expected to impart unacceptable latency for some usecases.

To mitigate this problem, some embodiments may implement a two-layerdata model in which a geographic area is quantized with a grid havingunit tiles, and identifiers of those unit tiles index into the subset ofbounding polygons within those unit tiles, such that identifying a unittile in which a point resides allows just the subset of polygons withinthat unit tile to be selected and compared to that point, potentiallyresulting in a dramatic reduction in compute resources needed to respondto a query in some designs. Further, in some embodiments, those unittiles may be addressed with, for example named by, identifiers thatcorrespond to their geographic area of coverage, for instance, by namingunit tiles according to a threshold number of significant digits oflatitude and longitude coordinates corresponding to their geographicarea. Or some embodiments may name tiles according to a location on aspace filling curve, like a Hilbert curve, Morton curve, or Z curve, andin some cases, those locations also correspond to a digitalrepresentation or binary representation of a threshold number ofsignificant digits of the geolocation coordinates.

In some implementations, a future geolocation of a user, or a movementof a user may generate a new geolocation for which an update to riskscores is requested. This may result in a query to the server system 12and the geographic information system 84 requesting information aboutplaces-of-interest encompassing the new geolocation, e.g., embodimentsmay receive a query specified by latitude and longitude of a point. Inresponse, some embodiments may truncate a threshold number ofsignificant digits, for instance, by discarding less significant digitsthan that threshold, appending the resulting to coordinates to oneanother or computing a hash value based on both coordinates to produce asingle value, and looking up the corresponding tile name with a contentaddressable lookup based on that single value that then returns thesubset of polygons of places-of-interest within the corresponding tile.Some embodiments may then execute a point-in-polygon algorithm on eachof those responsive subset of polygons to determine which include thepoint specified in the query.

A point geolocation be determined to be within a place-of-interest witha variety of techniques. In some cases, the place-of-interest may bedefined by a center point (e.g., a latitude and longitude) and a radius,and some embodiments may calculate a distance between the center pointand the point geolocation and determine whether the point geolocation iswithin the geofence by comparing the distance to the radius, withdistances exceeding the radius indicating the point geolocation isoutside of the geofence. In some cases, the place-of-interest may bedefined by a polygon having latitude and longitude vertices. Some suchembodiments may execute (e.g., on the client or server) a ray-castingalgorithm or a winding number algorithm to determine whether a currentlocation is within a geofence. For instance, some embodiments maydetermine whether a point geolocation is within a polygon correspondingto a geofence by counting a number of times a ray originating at thepoint geolocation intersects a side of a polygon defining a geofenceand, then, determining whether the point geolocation is within thegeofence based on whether the count is odd (corresponding to beinginside) or even (corresponding to being outside). In some suchimplementations, every edge of the polygon may be tested forintersection with the ray, and vertices may be tested for intersectionwith the ray and tracked in memory as already having been deemedintersected to avoid double counting of vertices for adjacent sides.Alternatively, or additionally, the point geolocation may be compared toa geofence by summing angles between rays extending from the pointgeolocation and vertices defining each sequential side of the polygon.Some embodiments may deem the point geolocation to be inside thegeofence in response to determining that the sum is non-zero. Someembodiments may calculate such angles according to an inversetrigonometric function, or to expedite processing and avoidcomputationally expensive calculations, some embodiments may leveragethe closed shape of the polygon and simply account for which quadranteach additional edge places each sum.

Some embodiments include the electronic medical record system 16 storingrecords indicative of medical conditions and healthcare histories ofusers, which may be interrogated to inform user profiles and variousrisk scores described below. Further, the user's risk score may bediscussed by a treating physician or other medical associate authorizedto access such information or presented to the user via the electronicmedical record systems mobile and web-based solutions.

In some embodiments, the computing environment 10 further include publicAPI servers 18 or private servers that expose APIs (or user-facinginterfaces suitable for scraping) from which data relevant to pandemicsurveillance may be obtained. Examples include weather data, trafficdata, census data, waste water data, telecommunication network footfalldata at the building or other bounding box level, commercial andresidential building infrastructure data, Department of Education datafor each school, including its district bounding box, physical location,number of students, faculty and administrators, animal infection data,Centers for Disease Control reports about prevalence of variouspathogens and variants thereof at various geolocations, social media andnews feeds with natural language text mentioning geolocations and havingdiscussion of prevalence of various pathogens and various geolocationsfrom which prevalence may be inferred, Centers for Disease Controlmodels of various pathogens (like R₀ and R_(t) values, case fatalityrates, vaccination rates, seroprevalence rates, the like), andcorresponding services from the World Health Organization and othercountries' governments.

Some embodiments may further include as part of the computingenvironment 10 computing devices of account holders or other entitiesauthorized to authoritatively report on attributes ofplaces-of-interest, as indicated by block 20. In some embodiments, theserver system 12 may host a web form or expose an API by which suchinformation be submitted. Examples of such information include types ofair filtration, rates of air turnover through the filtration system,whether the place-of-interest is indoors or outdoors, whether UVlighting is used to sanitize surfaces, cleaning protocols implemented atthe place-of-interest or certifications thereof, whether food isprepared at the place-of-interest, whether food is consumed at theplace-of-interest, demographics of people visiting the place-of-interestand density of people or number of people visiting the place-of-interestat various times of day, and the like.

Some embodiments may further include an administrator computing device22 by which the server system 12 may be configured and managed.

Some embodiments of the computing environment 10 may further include acomputing device of a healthcare worker 24 by which the healthcareworker interacts with the electronic medical record system 16 to accessrecords about patient medical conditions and other physiologicalattributes or demographic attributes of the user in the course ofproviding medical care. In some embodiments, user interfaces prompted byrisk scores calculated with the described techniques may be presented ona display screen or other output of the healthcare worker computingdevice 24, for example, in the manner described below with reference toFIG. 2.

The mobile computing device 14 may be any of a variety of differenttypes of computing devices that tends to be present with a user as theymove about their day. Examples include mobile phones, wearable computingdevices (like health trackers and head-mounted displays), in-automobilecomputing devices, tablet computers, laptop computers, and the like.

Personal Pathogen-Risk Index

Details of the pathogen-surveilling workflows of the server system 12are described in greater detail below with reference to the variousflowcharts and diagrams of data structures. In some embodiments, thismay include executing some or all of a process illustrated in FIG. 2 bywhich a personal pathogen risk score of a user is computed with process100. In some embodiments, the operations of process 100 may be executedentirely by the server system 12, entirely by the mobile computingdevice 14, or through cooperation of the of the two computing devices 12and 14. The illustrated operations may be executed in a different order,some operations may be executed multiple times, some operations may beomitted, some operations may have additional replications, andoperations may be executed serially or concurrently in any suitablepermutation, none of which two is to suggest that any other featuredescribed herein is not also amenable to variation. The samequalification applies to the various other processes and functionalitydescribed herein. Further, like the other processes and functionalitydescribed herein, the process 100 may be implemented by executing, withone or more processors, instructions stored in a tangible,non-transitory, computer readable medium, in some cases with the sameprocessor executing all instructions, or in some cases with differentprocessors executing different subsets of the instructions. In someembodiments, this process and the other functionality described hereinmay be implemented with one or more computing devices like thosedescribed below with reference to the last figure.

In some embodiments, the process 100 may be initiated responsive to auser request for a personal pathogen risk score, or in some cases, theprocess 100 may be initiated automatically, for instance during ascheduled batch process to update such scores, like run nightly or dailyor hourly, or responsive to an event that potentially affect such ascore, for instance, responsive to the user visiting a new location,supplying new information about their medical state, a person in thesocial graph of a user for whom the score is to be calculated providingnew information in these categories (like reporting an infection orexposure thereto), a place the user visited receiving updatedinformation (like a report that someone else contracted a virus at theplace-of-interest during a time the user visited or within somethreshold duration before their visit), updated information aboutattributes of such places that affect propensity of viruses or otherpathogens to be transmitted, or a change in a model from which suchscores are computed.

Some embodiments include obtaining a user profile of the user, asindicated in block 102. In some embodiments, this may include accessinga user profile that has been encrypted by accessing a corresponding keyin a trusted execution environment in accordance with the techniquesdescribed above. In some embodiments, a user profile or part thereof maybe encrypted and stored is a ciphertext on the mobile user device 14 anda key to decrypt that ciphertext may itself be encrypted and stored inthe same memory. Some embodiments may pass the ciphertext of that keyinto the trusted execution environment where it is then decrypted andused to decrypt the ciphertext in the memory accessible to the operatingsystem. Or in some cases, the entire ciphertext of the user profile ispassed of the trusted execution environment, where it is decrypted, andreturned for processing and plaintext form. In some embodiments,obtaining a user profile includes accessing user profile with the serversystem 12 described above. In some embodiments, the access may beauthenticated by the user of the mobile computing device, for instancewith by the user cryptographically signing a challenge, like a highentropy value, such as a random value of more than 256 bits, sent by theserver system 12 to the mobile computing device 14, which may cause thenative application 58 thereon to request the trusted executionenvironment to cryptographically sign the challenge value with a privatekey that is then reported back in the form of a digital signaturereported back to the server system 12 and used by the server system 12to verify that the party cryptographically signing the challenge hasdemonstrated proof of access to the private key without providing theprivate key outside of the trusted execution environment. In some cases,obtaining the user profile includes requesting information in the userprofile from the user, the electronic medical record system 16, or thevarious other third-party applications described above having data aboutusers, like calendar services, and social networks. In some embodiments,the profile of the user further includes a geolocation history of theuser, like lat-long timestamped breadcrumb histories or a history ofgeolocations in which the user has been determined to dwell at thegeolocation, such as a place-of-interest, for more than a thresholdamount of time, or a residence or work location inferred or specified bythe user. In some cases, dwells may be detected by the geolocationframework 60, the native app 58, the server system 12, or a third-partyservice like Radar™ for detecting geofence traversal and dwell time.

Embodiments may include obtaining a history of geolocations visited bythe user, as indicated in block 104. In some cases, these geolocationsare expressed as lat-long coordinates, tile identifiers, identifiers ofplaces-of-interest visited, or the like. In some cases, thesegeolocations in the history extend back a threshold duration of time,such as those in the within the last week, two weeks, month, or less orlonger. In some embodiments, the history of geolocations is obtainedfrom the user profile or from some other record. In some cases, suchgeolocations in the user's history may further include an elevationdimension, like a height or floor of a building.

Some embodiments include determining, based on the history ofgeolocations, geolocation-pathogen-risk scores corresponding to thegeolocations visited by the user, as indicated by block 106. These riskscores may be calculated with techniques described below with referenceto subsequent flowcharts. In some embodiments, thegeolocation-pathogen-risk scores may be precalculated and stored in thegeographic information system 84 by the server system 12. To obtain thescores, some embodiments may query the geographic information system 84with each visited geolocation in the history, which may includesubmitting queries for points-of-interest corresponding to (for example,encompassing in this context) lat-long coordinates in the geolocationhistory. In some embodiments, servicing this query may include the stepsdescribed above by which such queries may be expedited, using datastructures like those described below with reference to FIG. 3, which insome cases, may include multiple layers for some polygons correspondingto different floors of a building.

In some embodiments, the geolocations may be filtered to exclude thosefor which the user was present for less than a threshold amount of time,in some cases with that threshold depending upon attributes of thegeolocation, like the self-reported attributes described below that areindicative of how quickly various pathogens are expected to spread, forinstance, based upon airflow, filtering, and the like. In someembodiments, these thresholds also vary according to the pathogen andthe variant of the pathogen.

In some embodiments, as described in greater detail below, eachplace-of-interest responsive to such a query may include a plurality ofdifferent risk scores. The risk scores may indicate the likelihood ofcontracting a pathogen at the geolocation, or in some cases, aparticular room or floor of a place-of-interest. In some embodiments,each place-of-interest may be associated with a different risk scorecorresponding to each of a plurality of different pathogens. In someembodiments, each pathogen may have a plurality of variants incirculation, and some embodiments may include a variant-specific riskscore for the geolocation for each pathogen. In some embodiments, therisk scores may vary according to time, like time of day or absolutetime, for instance, due to an infected person visiting on a particularday, or a pattern in which more people are present during certain hoursat the place-of-interest. Some embodiments may store and determinepathogen-specific, variant-specific, time-specific risk scores for eachplace-of-interest, and in some cases, queries may specify a pathogen,geolocation, and time (like a time at which a user was at thegeolocation) to retrieve relevant risk scores. Or some embodiments mayaccess the full set of risk scores for all pathogens and all variants.In some cases, risk scores may be, or may correspond to, probability ofcontracting the corresponding pathogen at the geolocation. Determiningin this context may include retrieving a previously computed value orcomputing a new value of the geolocation-pathogen-risk scores. In somecases, risk scores for geolocations may be modified to account forthings that change over time, like density or amounts of visitors,weather, cleaning schedules, or the like.

In some embodiments the geolocation-pathogen-risk scores may, ratherthan being scalars, take the form of models or other functions fromwhich a personalized-geolocation-risk score can be calculated based uponattributes of a user's profile. For example, in some cases thegeolocation-pathogen-risk scores may take the form of a linear equationor trained machine learning model operative to receive as input severalparameters from a user's profile and output a pathogen, variant, andtime specific score customized to the corresponding user for thatlocation. For example, such a geolocation-pathogen-risk score taking theform of a geolocation-pathogen-risk function may have a linear equationwith a plurality of coefficients that have been curve fit based onhistorical data to predict a more individualized risk from exposure tothat particular pathogen, at a particular time, for a particularpathogen and variant of that pathogen, for that user. In someembodiments, these functions may be evaluated on the mobile device 14 orthat by the server 12.

Some embodiments may then determine a personal-pathogen-risk score ofthe user based upon the user profile and the geolocation-pathogen-riskscores corresponding to the geolocations visited by the user, asindicated by block 108. In some embodiments, these personalized scoresmay reflect an aggregate risk from exposure spanning a plurality ofvisited geolocations, in contrast to thepersonalized-geolocation-pathogen-risk scores described above based uponfunctions corresponding to the individual geolocations, times, variants,and the like. In some embodiments, the number of geolocations at issuemay be greater than two, greater than five, greater than 10, or greaterthan 50 for an individual.

Some embodiments determine the personal-pathogen risk scores bycomputing amounts of risk attributable to each of the geolocations(which may include future predicted geolocations for forecasted riskscores) and then combining the component risks into an aggregate riskreflecting the cumulative effect of the user visiting the variousgeolocations on risk of the user contracting the pathogen and variant atissue. In some embodiments, this combination may be a sum of theprobabilities corresponding to the different visits to differentgeolocations. In some embodiments, a single geolocation may have beenvisited multiple times, with different amounts of risk attributable tothat geolocation at each visit. Some embodiments may determine separatepersonal risk scores for contracting, being contagious, and suffering anadverse medical consequence (including death), as described below.

In some embodiments, the personal-pathogen-risk score of a user may alsobe based upon personal-pathogen-risk scores of other users adjacent theuser in a social network or within some other number of degrees ofconnection. In some embodiments, these personal scores may vary overtime, and the score used may depend upon when the user was in the samelocation as that member of their social network, using the score of themember of the social network being contagious from when the member ofthe social network was at the same location as the user for whom a scoreis being calculated. For example, if a user visits a friend or familymember who has a relatively high-risk score for being contagious, thatmay tend to increase the risk score for the user. Similarly, if the uservisits a friend who has, in the recent past, for instance, within somethreshold duration of time, themselves been present with several otherpeople who have relatively high personal-pathogen-risk scores for beingcontagious, then that may tend to drive up the rescore of the risk scoreof the user via the friend or family member's personal risk score forbeing contagious.

In some embodiments, the personal-pathogen-risk score is also based uponan individualized likelihood of the user contracting a pathogen ifexposed given that users demographic, psychographic, and physiologicalattributes. For example, children may be more or less susceptible tosome pathogens relative to older people. Similarly, gender, weight,ethnicity, and other attributes of a user may make them more or lesslikely to contract the pathogen if exposed. In some embodiments, thepersonal-pathogen-risk score may be adjusted after accounting forgeolocations visited with the user's likelihood of contracting ifexposed, for example by multiplying the probability of contracting ifexposed by the aggregate geolocation risk scores.

Some embodiments may further account for the likelihood of a personexperiencing an adverse medical result upon contracting the pathogen atissue or variant of pathogen at issue. In some embodiments, this maydepend upon the demographic and physiological (including medical historyand comorbidities) attributes of the user. In some embodiments, amachine learning model or linear equation may accept as inputs acollection of attributes of the user from the user profile and output aprobability of the user suffering a designated adverse medical eventconditional upon the user contracting the pathogen or variant at issue.In some embodiments, these models may be trained upon data reported tothe server system 12, in some cases after applying differential privacytechniques such that individualized data is less personally identifiablebut population statistics remain valid and suitable for training models.The types of events that qualify as an adverse medical event may vary bythe use case and may be predefined. Examples include staying in thehospital for a threshold duration of time, dying, missing work orschool, or the like. In some cases, multiple personal-pathogen-riskscores may be calculated for each for a different type of adversemedical event upon exposure and contracting pathogen at issue.

In some embodiments, these probabilities of an adverse medical event maybe weighted according to a confidence in the evidence for thoseprobabilities, which in some cases may be learned or in some cases maybe hand coded based upon, for example, medical journal articles. Forexample, a relatively high probability of an adverse medical event forwhich there is relatively little evidence or substantial variation amongthe existing evidence may be afforded a lower weight, which may tend tolower the personal-pathogen-risk score that is ultimately calculated,for example by multiplying the above-described modified intermediatepersonal-pathogen-risk scores by these weighted probabilities to producea final personal-pathogen-risk score or set of scores correspondingdifferent adverse medical events, in some cases for each pathogen atissue and in some cases for each variant of each pathogen at issue. Insome embodiments, a personal-pathogen-risk score may be calculated thataggregates among all variants for a given pathogen, and some embodimentsmay compute a personal-pathogen-risk score the aggregates among allpathogens as well. Thus, a user visit to a place where likelihood ofcontracting to different pathogens is moderate may result in arelatively high personal-pathogen-rescore when the effects of both ofthose pathogens are accounted for in the resulting aggregate score. Theterm “personal-pathogen-risk score” is used generically to refer to bothaggregate instances and the components of those aggregates as notedabove.

In some cases, different pathogens may combine synergistically to makeadverse medical events more likely. For instance, contracting COVID-19and the flu may be substantially more dangerous than either oneindividually. Some embodiments may maintain a two, three, or four orhigher dimensional matrix in which dimensions correspond to differentpathogens or variants thereof and values in the matrix indicate strengthof interactions therebetween. These values may be applied as weightswhen calculating aggregate personal-pathogen-risk scores that accountfor risk of an adverse medical event across multiple pathogens.

In some embodiments, information from electronic medical records fromsystem 16 may be accounted for when determining probabilities of anadverse medical event conditional upon contracting a pathogen or variantthereof. Some embodiments may retrieve these values from a user profileor directly from the system 16 to compute the personal-pathogen-riskscores. In some cases, different medical conditions may interact moreseverely with different pathogens or variants thereof. Some embodimentsmay train a machine learning model or have hand-coded rules to modifyrisk score to account for such medical conditions. The electronicmedical records system 16, in some embodiments, may render acomprehensive persona risk index for any pathogen taking into accountall of the patient data contained in the records system which may beviewed by the patient via a mobile app or web-based system oralternatively, presented by a treating physician during anypatient|doctor interaction (whether remote or in person).

In some embodiments, the personal-pathogen-risk score may then be storedin memory, as indicated by block 110, for example, in persistent ornonpersistent memory, like in program state accessed when facilitatingvarious forms of communication or risk mitigation techniques describedbelow with reference to subsequent flowcharts. For example, in somecases, the stored personal-pathogen-risk score may be compared against athreshold by the system 12 or system 16, and upon determining that thescore exceeds the threshold, some embodiments may cause the EMR system16 to present a user interface to a healthcare professional, like anurse or doctor operating device 24 in FIG. 1, prompting them to discussthe user's risk, adjust medical care to account for the user's risk, anddiscuss risk mitigation strategies with the user. In some embodiments,these user interfaces may be presented on the healthcare workercomputing device 24, which may be configured to interface with theelectronic medical record system 16. In some embodiments, the EMR systemcalculates the personal-pathogen-risk score after the algorithm isdeployed into the system. Once the algorithm is deployed, thepersonal-pathogen-risk score may be calculated for each patient file.The accuracy of the personal-pathogen-risk score may be dependent on theextend of medical histories needed to calculate the score. In the caseinsufficient information is present in a patient file, the EMR systemmay store a result “Unable to Score”. In this instance, the treatingphysical may ask the patient questions necessary to manually enter thepatient factors into the EMR system. The EMR system may then calculatethe personal-pathogen-risk score and allow the treating physician todiscuss the results with the patient. In the case basic information ispresent in any patient file, the EMR system may store apersonal-pathogen-risk score proxy. In the case comprehensiveinformation is present in a patient file, the EMR system may store apersonal-pathogen-risk score.

FIG. 3 illustrates an example of a data structure by which access toinformation about geolocations, given a geographic coordinate set, maybe expedited. As noted above, a relatively large number ofplaces-of-interest may be tracked, and computing a point-in-polygonalgorithm for every single place-of-interest in, for example, the UnitedStates, to respond to a single query for which place-of-interestincludes a latitude and longitude coordinate, is expected to becomputationally challenging and too slow for many use cases. To expeditesuch queries, some embodiments may implement a data structure by whichthe query term itself, like lat-long coordinates, index into a subset ofthe polygons, thereby excluding the vast majority of polygons from thepoint in polygon computation. In some embodiments, a geographic area maybe divided up according to a grid system 120 that may include aplurality of grid squares 122, which may take a variety of shapes otherthan squares, including rectangles, hexagons in a hexagonal tilingsystem, triangles in a triangular tiling system, or a variety of otherregular or irregular tilings. Irregular tilings may use larger tiles forareas with relatively few places-of-interest, for example in sparselypopulated rural areas, to afford more efficient use of memory, in someembodiments.

In some embodiments, each tile 122 may have an identifier or address ina data structure that corresponds to the geographic area it encompasses,and the identifier may correspond to how that geographic area isspecified in the query. For example, a given tile 122 may be at anaddress that corresponds to a point on a space filling curve or atruncated set of lat-long coordinates that excludes less significantdigits, such that each appended or hashed set of lat-long coordinatesspecifies some unit area, like a square kilometer, square meter, orsquare 10,000 km. Similarly, in some cases, the lat-long coordinates maybe truncated to some number of significant digits, excluding lesssignificant digits, converted to a binary number, which may then specifya point on a Hilbert curve or other space filling curve. In someembodiments, these addresses may then contain a pointer to the subset ofbounding polygons 124 within the tile 122 that is identified. In someembodiments, each of those bounding polygons 124 may correspond to aplace-of-interest, and the bounding polygons may specify the paceplace-of-interest with vertices 126 corresponding to latitude andlongitude coordinates that are associated with a unique identifier ofthe place-of-interest in the geographic information system 84. In someembodiments, each place-of-interest may further include a recordincluding the attributes of places-of-interest and corresponding riskscores of geographic places like those described elsewhere herein.

As noted, the geolocation-pathogen-risk scores andpersonal-pathogen-risk scores may have a variety of uses. In someembodiments, the above-described server system 12 may use one or both ofthe sets of scores for purposes of human load-balancing at places ofinterest (e.g., indoor or outdoor places). Some embodiments may obtainor predict a number of people at, or expected to visit, a geographicplace of interest, for example based upon currently reportedgeolocations or the above-describe techniques for predicting futuregeolocations of individuals. Some embodiments may modelgeolocation-pathogen-risk scores for the places of interest based uponpredicted visits from a collection of people predicted to visit. In someembodiments, the predictions may be weighted based upon confidence inpredictions of visits. Some embodiments may use these models todetermine how many, or which, people can visit within a duration of time(like one-hour windows, days, afternoons, or the like) without thegeolocation-pathogen-risk score exceeding a target threshold. Someembodiments may cause communications to be sent to users that wouldcause the predicted geolocation-pathogen-risk scores to exceed thatthreshold if visiting to not visit. For example, some embodiments maysuggest people not visit; some embodiments may interface with areservation server system to instruct the server system to ceasegranting additional reservations (or to cancel reservations); or someembodiments may send messages to people telling them that they areprohibited from visiting the places. In some embodiments, these humanload-balancing techniques may reduce the need for completeshelter-in-place restrictions in geographic areas, by dynamicallybalancing the load of human beings visiting places of interest, in somecases accounting for the personal-pathogen-risk scores of those humanbeings.

Some embodiments may allocate capacity at geographic places of interestwith various types of bin packing algorithms. Some embodiments mayidentify a collection of people predicted or requesting to visit adesignated place of interest. Some embodiments may obtainpersonal-pathogen-risk scores of potential visitors, such as likelihoodof those people having a designated pathogen or being in a contagiousphase of such an infection. Some embodiments may optimize which peoplevisit the place of interest in a designated time. For example, someembodiments may execute a greedy bin packing algorithm in which usersare taken in order of identification and time slots are filled until thepredicted geolocation-pathogen-risk score would cross the threshold ifadditional people were added. Some embodiments may apply morecomplicated algorithms to allocate scarce capacity. For example, someembodiments may mix people who have been vaccinated or have already hada virus with those who are presenting greater risk to increase thenumber of people who can visit at a designated time slot.

Some embodiments may implement cross-border risk indexing. In somecases, the above-describe server system 12 may computecountry-to-country risk scores based upon the exposure risk from peopledeparting a country A (taking into account each person's home addressand the city of departure and the corresponding location risk indexesfor their home and departing city) and traveling to a country B. In somecases, these risk scores may be modeled as a matrix in which a list ofcountries corresponds to rows and the same list of countries correspondsto columns, with values indicating the risk of moving from a row countryto a column country. In some cases, the same technique may be applied tosmaller geographic units, like movement between counties, states, ormunicipalities. Some embodiments may integrate with a country's customsand border enforcement system or air traffic or ship information systemto transmit messages identifying relatively high-risk travelers, such asthose scoring higher than a threshold, transiting between countries. Insome embodiments, the system 12 may ingest flight manifests, as well asmanifests from other modes of travel, like trains, ships, and the like,and create an inbound risk score for people coming into a country. Insome cases, these inbound risk scores may be the personal-pathogen riskscores for individuals that are inbound.

Location Pathogen-Risk Index

Some embodiments of the server system 12 may execute a process 140illustrated in FIG. 4 to analyze pathogen risk by geolocation. In somecases, the process 140 or subsets thereof may be executed periodically,like daily, hourly, weekly or more or less often, or responsive tovarious events, like updates to the data upon which operations arebased. In some cases, the data operated upon may have a relatively largescale, for instance consistent with the examples described aboveregarding the number of users and geographic coverage. To this end, thetechniques described above for expediting processing on large data setsmay be implemented, including the approaches related to streamprocessing and complex event processing systems with compute clustersthat implement resilient distributed data sets, in some cases incombination with the machine learning techniques described herein.

In some embodiments, the process 140 may include obtaining geolocationsfrom a geographic information system (like GIS 84), including bothgeographic regions and places of interest within those geographicregions, as indicated by block 142. In some embodiments, the geographicinformation system may organize data about geographic areas according toa hierarchical data structure in which some geolocations contain othergeolocations which may then themselves contain additional smallergeolocations. In some cases, the obtained a geolocation may be thosepertaining to a particular query, like a query specified by the userdrawing a bounding box upon a map extent in a user interface, or thegeolocations may be a comprehensive set of geolocations in a geographicarea or the entirety of the geographic information system, for instance,during operations supplementing a batch process to update risk scoresfor a country. The geolocations, as indicated may be geographic regions(like reporting districts, such as counties, ZIP Codes, states,parishes, or other geographic areas over which data is to be aggregated,including the other examples described herein) and some may be places ofinterest (such as businesses, residences, parks, stadiums, and the like,including the other examples described herein). The obtainedgeolocations may be in the form of identifiers thereof, such as uniqueidentifiers of those geolocations within the geographic informationsystem, and in some cases, the obtained geolocations may includeadditional attributes of those geolocations, like bounding polygons,names, aliases, unique identifiers in other name spaces, and the like.

In some embodiments, the process 140 includes obtaining static dataabout the geolocations, as indicated by block 144. In some embodiments,the static data is data that is updated less frequently than thebelow-described dynamic data. Examples of each include those examplesconsistent with their properties described elsewhere herein. In somecases, the static data never changes, or in some cases, the static datachanges less frequently than once per month, once per year, or once perdecade. In some cases, the static data is not pathogen specific, forinstance, the static data may remain the same regardless of whatpathogen is it at issue. Examples of static data include those examplesin the applications incorporated by reference, such examples includingcensus data, data from an organization's identity management or payrollsystem that indicates which employees or other visitors to thefacilities are assigned to which facilities, attributes of geolocationsthat are independent of pathogen prevalence at those geolocations, andthe like. In some cases, the static data may include identifiers ofgeolocation in a name space or a plurality of name spaces of varioussources of the static data (like servers 18), and in some cases thegeographic information system may associate identifiers in other namespaces with a native namespace of the geographic information system,correlating a canonical identifier with third-party identifiers. In somecases, the static data may be obtained from third-party data sources,for instance, by querying various APIs exposed by, for example,governmental agencies, universities, real estate records, and the like.

In some embodiments, the process 140 includes obtaining dynamic dataabout the geolocations, as indicated by block 146. In some embodiments,the dynamic data is updated more frequently than the static data, suchas more often than monthly, weekly, daily, or hourly. In someembodiments, the dynamic data is pathogen specific, for instance,pertaining to numbers or per person or per unit time rates of infection,hospitalization, death, vaccination, immunity, of various pathogens andin some cases variants thereof. In some embodiments, the dynamic dataincludes time series data indicating such values over a trailingduration of time, like since the beginning of a pandemic. The dynamicdata may also be obtained, in some cases, from third-party data sources,for instance by querying various APIs exposed by governmental agencies(e.g., the Centers for Disease Control), universities, hospital systems,not for profits, and the like, with additional examples discussed above.In some cases, the dynamic data may include information from theabove-described native applications 58, upon users consenting to suchuse, and upon the information being anonymized, in some cases withdifferential privacy techniques, or some embodiments may operate withoutinformation supplied by individual users of the mobile application,which is not to suggest that any other feature described herein is notalso amenable to variation. In some cases, some of the dynamic data maybe obtained as a batch download from an API exposed by a third-partyserver (e.g., servers 18), or some dynamic native data may be receivedthrough push communications, for instance, upon registering a callbackfunction with such third-party servers or other applications.

Some embodiments include determining geolocation-pathogen-risk scores ofthe geographic regions, as indicated by block 148. In some embodiments,scores of the regions may be determined before scores of the places ofinterest in those regions, or vice versa, in some cases with scores inone being based upon scores in the other. In some embodiments, thescores in the geographic regions may be based on both the static dataand the dynamic data. In some cases, the dynamic data is not reported atthe level of geographic granularity corresponding to at least someplaces of interest. In some embodiments, at least some of the dynamicdata may be reported, and thus obtained, at lower levels of geographicgranularity, for instance, corresponding to the geographic regions. Insome embodiments, different portions of the dynamic data may havedifferent levels of geographic granularity. For example, positive testrates for infection or seroprevalence, hospitalization rates,vaccination rates, immunity rates, or accounts thereof, may be reportedat the county level from various third-party servers or other datasources. In some embodiments, the static data may be more granular thanthe dynamic data, less granular, or portions thereof may have thisproperty.

In some cases, the geolocation-pathogen-risk scores may correspond to,for instance, be output by statistical or machine learning modelsconfigured or otherwise trained to compute, mean, median, mode, 80thpercentile, 95th percentile, or some other representative characteristicof a distribution probability of contracting a corresponding pathogen,being hospitalized due to infection, dying due to infection, missingwork or school due to infection, or the like. In some cases, differentscores may be calculated for a given pathogen for each of theseoutcomes. In some cases, different scores may be calculated fordifferent variants of a given pathogen. In some cases, the scores may beindependent of behavior or attributes of any one individual, forexample, indicating a baseline level of risk designed to be informativeto a broad swath of the population, managers, or policymakers. In somecases, the model may be hand coded, for instance, using epidemiologicalmodels from the art (e.g., based on SIS, SITR, SIRD, MSIR, SEIR, SEIS,or other models), or in some cases, machine learning models may betrained based upon historical behavior of the pathogen or a collectionof pathogens. For example, a machine learning model like that describedbelow for places of interest may also be trained for the geographicregions. In some cases, each of these scores may also be calculated fordifferent segments of time, for example, with different portions of theday (like morning, evening, afternoon, or night, or one hour segments),different portions of the week (like weekdays and weekends, or each weekday of the week), or different seasons of the year, indicating differentlevels of risk based upon different attributes of the geographic regionat those times.

Some embodiments include determining geolocation-pathogen-risk scores(for example any of the forms described herein) of the places ofinterest with a machine learning model, as indicated by block 150.Examples of such models include empirical Bayesian kriging (EBK), EBKwith independent variables, ordinary least squares (OLS) regression,geographically weighted regression (GWR), and those described in Du, P.,Bai, X., Tan, K. et al. Advances of Four Machine Learning Methods forSpatial Data Handling: a Review. J geovis spat anal 4, 13 (2020), thecontents of which are hereby incorporated by reference. In some cases,the machine learning model may be trained to allocate risk of geographicareas down to places of interest within those geographic areas, forexample, unevenly on to different places of interest (which may includesubregions of the geographic areas) based upon attributes of thoseplaces of interest, such as attributes in the static data or in somecases the dynamic data where the dynamic data is obtained withsufficient granularity. In some cases, this down projecting of risk maybe performed at multiple levels of a hierarchical segmentation of ageographic area, like three, four, five or more hierarchical levels ofsegmentation, which may include regular tilings like a quad tree orirregular tilings, such as often are implemented in subdivision ofgeographic areas by municipalities and states. In some cases, someplaces of interest in the geographic region may be determined by themachine learning model to have a higher risk than other places ofinterest in the same geographic region based upon attributes of thoseplaces of interest. Examples of such attributes include density ofpeople, density of movement, vaccination rates, immunity rates,seroprevalence rates, and the like. In some cases, the scores may alsocomputed for different segments of time according to attributes of theplaces of interest during those segments of time, like as describedabove for the scores for the geographic regions. In some cases, placesof interest may include hyperlocal places of interest, such as thosethat are smaller than 1000 m², 2000 m², or 5000 m². In some cases, theplaces of interest may further be segmented by floor or room of abuilding (which may themselves be places of interest), like a multistorybuilding, with different floors or rooms therein having differentscores. In some cases, the scores may be based upon the self-reportedattributes of the buildings discussed above, with things like open-airflow and robust ventilation or clean schedules tending to drive downrisk in rooms, floors, or buildings in which those attributes apply.

The machine learning model may take a variety of forms in addition to(and in some places in combination with, like in an ensemble model, theexamples above). Examples include decision, regression, orclassification trees, or ensembles thereof, like random forest machinelearning models. Some embodiments may input a plurality of featurespertaining to the place of interest, such as the types of attributesdescribed above of such places of interest, like five or more features,10 or more features, or 50 or more features. In some cases, thesefeatures may define an input feature space having a corresponding numberof dimensions. Some embodiments may implement binary recursivepartitioning, e.g., some such embodiments may iteratively bisectrespective dimensions of that feature space in each iteration, testingdifferent locations to bisect on the respective dimension to select thelocation on that dimension (and in some cases the next dimension tobisect) that minimizes entropy or Gini impurity in the volumes on eitherside of the value in the respective dimension. In some cases, theentropy or Gini impurity (which may be generically referred to as ameasure of impurity) may indicate which weight (or a linear segment of aweight curve or planar weight surface) in a range of discrete weightvalues best characterizes allocation of risk from geographic regions toplaces of interest in historical data at the corresponding volume in theinput feature space. In some cases, the splits may be determined with agreedy optimization that optimizes for minimizing such measures ofimpurity at each iteration. Some embodiments may further implementpruning to reduce the risk of overfitting, e.g., by thresholdingaccording to a cost complexity factor.

In some cases, the machine learning model may take the form of a deepneural network operative to transform inputs into a corresponding outputweight. For example, the deep neural network may include a plurality oflayers of perceptrons having connections (by which outputs flow toinputs) therebetween with parameters adjusted during training referredto as biases and weights (which are different from the weights output bythe model) for each perceptron. In some cases, the number of parametersof the model adjusted during training may be greater than 1000, 5000,10,000, or 50,000, and the model may be said to have a correspondingnumber of degrees of freedom.

In some cases, training may be implemented with stochastic gradientdescent using back propagation. In some cases, training may includeiteratively computing a partial derivative of each of the respectiveparameters of the model adjusted during training with respect to anobjective function, indicating a local slope that indicate a directionto adjust the parameter according to some stride value that may be ahyper parameter to locally further optimize the objective function. Insome cases, the objective function may be a fitness function indicatinghow well the model (at a current iteration of training) characterizesrelationships in a training set or a loss function indicating how poorlythe model (at a current iteration of training) characterizes suchrelationships. In some cases, training may be repeated multiple times byselecting random initial values for the parameters during each trainingrepetition to reduce the risk of landing in a local minimum, and thetraining repetition producing the most optimal outcome of the objectivefunction may be selected as the trained version of the model. In somecases, training iterations may repeat until a change in the objectivefunction between successive iterations is less than a threshold value,indicating a minimum or maximum.

In some cases, some training data may be withheld from training and useto cross validate the train models by testing the train models on thewithheld training data and computing a value like an F-score. Someembodiments may determine whether this score satisfies a threshold (forexample is greater than the threshold for values that tend to increasewith quality or is less than the threshold provides the tend to decreasewith quality). Some embodiments may also implement techniques likebootstrap aggregation to further extend the value of training sets, withsome training examples occurring in multiple training repetitions, forexample, by randomly selecting from a training set to form batches, forinstance, either with or without replacement, each batch being a subsetof the training set, and each batch used to train a repetition oftraining.

In some cases, the resulting weights output by the models may benormalized, e.g., over the geographic region at issue. For example, someembodiments may divide each of the weights by a sum of all of theweights to produce a coefficient. Or in some cases, this sum may includeadditional values to reflect regions for which weights were not obtainedfor places of interest. In some cases, the resulting coefficients forall place of interest in a region may sum to one. Some embodiments maythen multiply the coefficient of each place of interest by thegeolocation-pathogen-risk score of the corresponding region to producethe down projected geolocation-pathogen-risk score of the respectiveplace of interest.

Some embodiments include storing the geolocation-pathogen-risk scores ofthe places of interest and the geographic regions in memory, asindicated by block 152. In some cases, these values may be stored inpersistent or dynamic storage, for example, in program state or writtento disk or a solid-state drive in a database, like in the geographicinformation system in a record corresponding to each of the geolocationsto which the scores apply. In some cases, these scores may be computedat query time, when a query is received by the geographic informationsystem requesting such scores, or the scores may be computedperiodically or responsive to some event as a batch process, forinstance, for all geolocations characterized by the geographicinformation system.

The stored scores may have a variety of uses, some examples of which aredescribed above, and some of which are illustrated in FIG. 4. Theseoperations, like the steps of the other processes described herein, insome cases may be omitted in some embodiments, which is not to suggestthat any other described feature is required in all cases.

In some embodiments, the machine learning model or models may undergoactive learning. In some cases, this may include retraining themachine-learning model based on new dynamic data, as indicated by block154. Some embodiments may perform a full retraining operation, or someembodiments may initialize the retraining model to the parameters of theexisting model, using a training set that reflects newly arrived data.In some cases, retraining may include training a new model downstream ofthe existing model that learns to correct error in the existing modelwhen the existing model is used to predict outcomes in the new trainingdata.

Some embodiments include scoring facilities of an organization accordingto geolocation-pathogen-risk scores of places co-visited by thosevisiting the facilities or expected to visit the facilities. Forexample, an employer, like a corporation or governmental entity, maymaintain an account in the server system 12 indicating which places ofinterest are facilities of that entity, and in some cases, that entitymay query the server system 12 for a reporter indicating such scores. Insome cases, the risk scores may reflect behavior of people who visit thefacilities or are expected to visit the facilities, such as places wherethose people reside, travel, or work outside of the facilities (orsimilar attributes of people adjacent those facilityvisitors/potential-visitors in a social graph).

In some cases, those predicted to visit a facility may be obtained byquerying a calendar or scheduling software or customer relationshipmanagement or enterprise resource planning system, for instance, forscheduled visits by customers, contractors, or vendors. In some cases,those who visit or are predicted to visit may also be obtained frompayroll systems or identity management systems of the entity. In someembodiments, the information about such individuals may be stripped ofpersonally identifying information and may be anonymized or renderedpseudonymous in information sent to the server system 12. In someembodiments, operation on such information may be executed in afederated manner, with code running within computing devices owned orcontrolled by the entity operating the facilities based upon geolocationrisk scores reported by the server system 12 before aggregate outcomesare reported back to the server system 12, thereby reducing the entity'scybersecurity attack surface for those seeking to obtain privateinformation about those who visit the facilities. Or some embodimentsmay report this information back to the server system 12, for instanceconveying the information in encrypted format in appropriatelyanonymizing records.

In some cases, embodiments may obtain other geolocations visited bythose expected visit or who have visited the facilities, like residencesof employees, and determine a risk score for the facility based upongeolocation-pathogen-risk scores of those residences or regions of thoseresidences. For example, if a subset of employees visiting a facilityreside in a relatively high-risk area, that information may tend toincrease the facility risk score. In some cases, lower granularitycharacterizations of co-visited places, like residences, may be used toenhance privacy and limit access to the server system 12 of individualsprivate addresses. In some cases, the facilitiesgeolocation-pathogen-risk score may be a measure of central tendency(for example mean, median, or mode) of the scores of the co-visitedplaces, a visit duration or frequency weighted version of such a measureof tendency, a worst-case or greater than a threshold percentage (like90th percentile highest risk) risk score of co-visited geolocations, ora visit duration or frequency weighted version of such a score. In someembodiments, a given person may co-visit a variety of differentgeolocations, and multiple co-visited geolocation risk scores may beaccounted for when processing information corresponding to thatinformation that individual. Or in some cases, a machine learning modellike those described above may be trained to predict facility riskscores based upon the co-visited place's geolocation-pathogen-riskscores.

In some cases, the visitors, either current or expected, of thefacilities may be grouped according to their risk contributions. Forexample, some embodiments may segment visitors of the facilitiesaccording to geolocation-pathogen-risk scores of their co-visited places(e.g., previous places they visited), as indicated by block 158. In somecases, the segments may be referred to as risk pods. In someembodiments, these risk pods may be relative segmentations, like tophalf and bottom half of risk, or absolute segmentations, like those withgreater than a 10% chance of infecting others, the those with greaterthan a 50% chance of infecting others, and those with greater than a 90%chance of infecting others (or risk of being infected, risk of beinghospitalized, or risk of dying). In some cases, these segments may bepresented in reports to management of such organizations, like thoserunning schools (e.g., students co-visits may affect risk of a schoolfacility), governmental agencies, or corporations or not for profits. Insome cases, the segments may be presented without identifyingindividuals in the segments in the report, but indicating groupstatistics, like a number of people in the segment. In some cases, theuser interface with which the information is presented, for example, ina computing device of those in management, may further include a userinput to select or otherwise request communications to some of thegroups produced by the segmentation, for instance, causing an email,text, or push notification to be sent to those in a relatively high risksegment, instructing them to not come to the facility and work fromhome, or a similar type of communication to those in a low risk segment,informing them that the risk has been analyzed and they are clear tocome to work and that those in higher risk groups have been asked to notcome to work. In some cases, such communications may be conveyed via theabove-described mobile application, or communications may be sent toother network addresses, like email and phone numbers for text or audiomessages, or via social media feeds of users.

In some embodiments, the user interface presented to management offacilities may also indicate the geolocation-pathogen-risk scores ofthose facilities computed based upon the scores of co-visited places. Insome embodiments, the user interface (which like the other userinterfaces described herein, may evolve over time to reflect differentinformation and respond to user inputs while still constituting “the”user interface, that is an antecedent of the term “the user interface”may display different information that that presented when “the userinterface” is subsequently referenced) may depict a map of thefacilities, with color coding or other visual weight applied to indicaterisk of the facilities. For example, a spectrum of color may be scaledaccording to a range of risk scores, and facilities with particular riskscores may have corresponding colors applied in the user interface. Insome cases, the user interface includes event handlers responsive touser selection of individual facilities (for example clicking on,touching, gazing at, or the like) to update the user interface to depictadditional, more detailed information about those facilities, like whichgeographic regions account for which portions of the risk, a depictionof the segments of visitors to that facility according to theabove-describe segmentation according to risk of visitors, or some othercharacterization of the distribution of individual contributions to therisk to help inform decision-making.

Some embodiments include scoring pathogen risk of transit (e.g., trip)by vehicle (e.g., ship, train, subway, bus, car, plane, etc.) accordingto geolocation-pathogen-risk scores, as indicated by block 160. Examplesinclude scoring transit in vehicles in which multiple people areconveyed concurrently. In some cases, a manifest indicating which peopleare all to be conveyed may not be available, and some embodiments mayscore pathogen risk of transit based upon the departing geolocation, forinstance indicating high risk for plane flights from a region with ahigh infection rate. In some cases, manifests may be available, forexample, indicating anonymized or pseudonymous identifiers of thosetraveling and, in some cases, previous places those individuals havetraveled. Some embodiments may score the transit according to thoseprevious visits in the manner described above where visitors to afacility contribute to risk according to co-visited places of thoseindividuals.

Some embodiments may determine a personalized geolocation-pathogen riskscore, as indicated by block 162. In some cases, the server system 12 ornative application 58 may cause individuals to be presented withcustomized messages to reduce their risk of pathogens. Some embodimentsmay determine some measure of a user's responsiveness to those messages,like a response rate or risk severity weighted response rate. Based uponthis measure of responsiveness, some embodiments may determine thepersonalized pathogen risk score of the individual for the geolocation,with those that tend to be less responsive to messaging being presentedwith a higher score. In some embodiments, users may input an enhancementfactor during the onboarding process or by configuring settings in thenative application 58, such as a personalized risk scaling preference toindicate that they wish to be particularly cautious (or less cautious),and those individuals may be presented with a personalizedgeolocation-pathogen-risk score that is scaled (or offset) upwards ordownwards based upon that setting, with other operations that dependingupon that score particular to the user being similarly modified.

Some embodiments may include routing people or goods according to thegeolocation-pathogen-risk scores, as indicated by block 164. In somecases, this may include monitoring and adjusting a logistical supplychain to reduce pathogen risk. For example, some pathogens may havefomite transmission and goods from areas with the pathogen may tend tocause its transmission, and suppliers in regions with high risk may tendto be less reliable. Some embodiments may obtain a sequence ofgeolocations in such as supply chain or travel route for an individual.Some embodiments may determine or obtain a plurality of alternatesequences of geolocations corresponding to different vendors orfacilities in supply chain or different routes of travel. Someembodiments may obtain geolocation-pathogen-risk scores of eachgeolocation in each of the sequences of the different routes, and someembodiments may determine an optimal or reduced risk route to selectamong those candidates. In some cases, the candidate geolocations alongthe various routes may be represented as nodes in a graph with directedweighted edges indicating risk of goods or people leaving that node.Some embodiments may further weight the edges based upon cost, distance,or transit time to produce a risk-adjusted weight corresponding to goodsor people leaving the respective node to go to subsequent nodes in asequence. Some embodiments may compute a path across the graph (e.g.,from a starting node or candidate nodes to a destination node) thatminimizes the risk-adjusted score or keeps each edge along the path atless than a threshold pathogen risk. The resulting path may be selected,or a risk-ranked listing of such paths may be presented in the userinterface for users to select among to reroute goods or people.

Some embodiments include presenting a user interface based upon thegeolocation-pathogen risk scores, as indicated by block 166. Examples ofsuch user interfaces are described above. In some embodiments, the userinterface may include a map (e.g., a scalable and pannable map)depicting a map extent, and the user interface may be responsive to (forinstance with user input responsive event handlers) user inputs toselect an area of the map, for example, by drawing a bounding box. Someembodiments may receive the selection and query the geographicinformation system 84 for geolocation-pathogen-risk scores ofgeolocations within the area designated by the bounding box. Someembodiments may update the user interface to depict these risk scores,for instance, using the above-described color coding scheme. In somecases, the user interface may be responsive to user selection ofindividual places of interest or geographic regions to update the userinterface to depict a time series depiction of thegeolocation-pathogen-risk score of the selected geolocation, forinstance, since the beginning of a pandemic (or to show a predictedtrend for such a score), and in some cases, depicting the relativecontribution of subregions, like places of interest, to the aggregatescore of the selection, for example, using the above-described colorcoding schema. In some cases, the user interface may be presented in aweb browser of a remote user's computer or in the above-described nativeapplication 58, each through communication with the server system 12 vianetwork 26, or in a computer executing the code described above withreference to the system 12, for example in a monolithic implementation.

In some embodiments, the process 140 may include producing resultsuseful for policymakers, like indications of which static or dynamicdata tends to drive or correlate with various outcomes (like infection,hospitalization, loss of work days or school days, vaccination, death,or the like). For example, some embodiments may use principal componentanalysis, multi-variate analysis, dynamic Baysean networks, do-calculus,or other statistical techniques to determine which static variables ortypes of messaging or policy choices correlate with, or cause, changesin geolocation-pathogen-risk scores or these other outcomes. Someembodiments may use machine-learning models designed to be interpretableto output results indicating which input features or intermediate-layerfeatures exhibit correlation with outcomes. In some cases, these outputsmay be presented in a report in a user interface on a policymaker' scomputing device through communication with the server system 12 vianetwork 26.

Behavior Modification Messaging

Some embodiments implement a behavior modification messaging process 180illustrated in FIG. 5. In some embodiments, this process 180, orportions thereof, may be executed responsive to events in real time (forexample within less than one minute, less than five seconds, or lessthan 500 ms, of receiving an event prompting execution). In some cases,the process 180 may be initiated responsive to an event indicating auser is predicted to visit a geolocation, for instance with thetechniques described above, like based on API access to user calendars,inferred next locations determined with machine learning models, likelong short term memory networks or hidden Markov models, or the userexpressly indicating through use of the native application 58 that theyintend to travel to a geolocation. Or in some cases, the process 180 maybe executed responsive to a determination that the user has arrived at ageolocation, for instance, crossed a geo-fence corresponding to ageolocation, their mobile device 14 has sensed a wireless beaconbroadcast at the geolocation, or the user has expressly indicated thatthey are at the geolocation through input to the native application 58.In some cases, the process 180 may be executed as a batch process, forinstance, hourly, daily, or weekly.

In some embodiments, the process 180 may be executed by the serversystem 12, for example by the natural-language-text generation model 79or in cooperation with that model, for example, at the direction ofcontroller 74, as shown in FIG. 1 above. In some embodiments, the serversystem 12 may include a finite state machine 81 that implementsorganizational messaging to manage pathogen risk, as described ingreater detail below with reference to FIGS. 6 and 7.

In some embodiments, some operations may be performed by the mobilecomputing device 14, for example, by the native application 58. Like theother processes described herein, the computer system implementing thisprocess 180 may be solely constituted by the server system 12, solelyconstituted by the mobile computing device 14, or a combination thereof,for example in distributed applications, or some embodiments may rely onthird-party computing hardware as well.

In some embodiments, the process 180 begins with obtaining a nextgeolocation to be visited by the user, or at which the user has arrived,as indicated by block 182. In some cases, this step of obtaining stepmay be implemented by obtaining an event like those described aboveindicating such an occurrence. In some cases, the next geolocation maybe obtained from mobile device 14, and the next geolocation may include,or map to (e.g., in a one to one or one to many relationship), a recordthat is stored in, and retrieved from, the above-described geographicinformation system 84. In some embodiments, the next geolocation may beobtained as part of a sequence of geolocations the user is visiting, hasvisited, or is expected to visit. In some embodiments, the user may haveonly visited a subset of the sequence and some geolocations in thesequence may be predicted. Or in some cases all geolocations in thesequence may be predicted.

In some cases, where the user has already arrived at the geolocation,step 182 (like 182 to 190) may be performed within a relatively shortduration of time of arrival, for instance within less than 20 minutes,like less than five minutes or less than one minute of arrival. In somecases, arrival may be detected by the native application 58, uponreceiving an event are function callback from a geolocation frameworkexecuted by the mobile computing device 14, for instance, provided bythe operating system 56 (like a corelocation framework in iOS™ orCLLocationManager framework in Android™) indicating such arrival. Insome cases, where a sequence of geolocations is obtained, both thegeolocations and dwell times thereof may also be obtained to producedwell-duration weighted scores.

Some embodiments include obtaining a geolocation-pathogen-risk score ofthe next geolocation, as indicated by block 184. In some cases, this mayalso include obtaining geolocation-pathogen-risk scores of eachgeolocation in a sequence of geolocations visited or that are to bevisited. In some embodiments, the score may be obtained by queryingrecords corresponding to the geolocations in the geographic informationsystem 84, which may be stored there in advance by executing the process140 of FIG. 4. Or in some cases, the scores may be updated in real timeby executing some or all of the process 140 (or the scores may becreated for the first time if they do not exist by executing process140, e.g., within less than 5 seconds, like within 150 ms). Or in somecases, the scores may be obtained from a third party.

In some cases, messages presented to users may be rate limited, to avoidoverwhelming users and messages losing salience. For example, someembodiments may limit the number of messages presented to a user to lessthan some threshold per trailing duration of time, like two per 24 hourperiod of trailing duration, or two per day. In some cases, thisthreshold may be modulated based upon the risk score, for instance, someembodiments may determine to permit a third message in this example upondetermining that the risk score exceeds some threshold, and someembodiments may extend that to a fourth message upon determining thatthe risk exceeds some even higher threshold.

Some embodiments include determining a topic of message based on thegeolocation-pathogen-risk score, as indicated by block 186. In somecases, the message may be based upon the scores for a sequence ofgeolocations, for instance, based upon a maximum score, a durationweighted average score, an average score, a 90th percentile or someother threshold score or the like. In some cases, ranges ofgeolocation-pathogen-risk scores (or ranges of types of such scores) maybe modified by users specified factors that indicate a user's preferencefor being particular risk adverse or risk tolerant, like those discussedabove. In some cases, ranges of such scores may further be modifiedbased upon a user's pattern of complying with behavior modificationmessaging, for instance, with personalized geolocation-pathogen-riskscores like those discussed above.

In some embodiments, ranges of such scores may be mapped to topics, andin some cases first or second derivatives of such scores with respect totime or sequence of geolocations in a sequence may be computed andranges of those derivatives may also be mapped to topics. Examples oftopics include warnings of high risk, all clear signals, warnings ofincreasing risk, warnings of accelerating risk, warnings to take riskmitigating actions, indications that risk mitigating actions can bereduced, and the like.

In some cases, each topic may correspond to a larger body of candidatespecific natural language expressions of messages within that topic. Forexample, the “warning of increasing risk” topic may apply both to anatural language text message that “risk is increasing rapidly over thelast two weeks for pathogen X at your next geolocation Y” and a naturallanguage text message that “risk of infection is trending upward here.”

In some cases, these natural language text messages in each topic may beprewritten, for instance, with more than 5, more than 50, or more than500 in a corpus segment for each topic. In some cases, those messagesmay be implemented as templates, with fields that are populated tocustomize the message for a given context or person, consistent withexamples described below. Or in some cases, the messages are generatedwithout a template, for instance, from scratch by certain embodiments ofthe natural-language-text generation model 79 described below. In somecases, these candidate bodies of text, or inputs to produce thosecandidate bodies of text, and models relevant thereto may be part of thenatural-language-text generation model 79 shown in FIG. 1.

Some embodiments may determine with a natural-language-text generationmodel, natural language text within the determined topic, as indicatedby block 188. In some cases, this may include selecting amongpre-written bodies of text, each corresponding to a different expressionconsistent with the topic. Examples include randomly selecting amongbodies of natural language text in a corpus that are mapped to the topicin advance. In some cases, the probability of selecting variouscandidate messages in such a corpus for topic a may be modified basedupon feedback, such that those messages tending to produce morecompliance are more likely to be selected, but without repeating thesame message again and again with excessive frequency.

For example, each such candidate message may be mapped to a range ofintegers between 0 and 10,000, and the size of the range mapped to eachcandidate message may be selected in accordance with the feedback, suchthat feedback indicating compliance tends to widen the range, andfeedback indicating the absence of compliance tends to narrow the range.Some embodiments may then select a random number, like a pseudorandomnumber, between zero and 10,000 and then select the message textassigned to a range including that random number. In some cases,different ranges corresponding to different probabilities of beingselected may be computed based upon feedback according to demographic orpsychographic segment of those to which the feedback pertains, therebymaking certain messages that tend to work well with a certaindemographic, for example, more likely to be selected to be presented toother members of that demographic. In some cases, when the message is tobe determined, the range corresponding to the user's demographic orpsychographic segment (which may be determined with techniques discussedbelow) may be used to compare to the random value that drive selectionamong those messages pertaining to a topic in the corpus. In some cases,selections may be rejected or candidates may be withheld from theselection based upon those messages having been presented to the userwithin some trailing duration of time or trailing number of messages ina sequence of messages sent to that user, to avoid having repetitivemessages sent to the user.

In some embodiments, the corpus of candidate messages may includetemplates having fields that can be customized for a context or person.In some embodiments, these fields may be mapped to queries to userprofiles or other indicia of context, like weather, attributes of theplace of interest, time of day, previous places or subsequent places ina sequence of places, a category of place being visited, or category ofactivity to be engaged in at the place to be visited. Some embodimentsmay maintain an ontology of places, like a hierarchical ontology and anontology of activities, like a hierarchical ontology of activities.Examples include such an ontology indicating the category of restaurantsincludes the subcategory of Italian restaurants, which includes asub-subcategory of northern Italian restaurants, which includes aspecific place of interest to be visited. Similarly, some embodimentsmay include the activity of sports, which may include sub-activity ofgolf, which may include golf at a particular place of interest. In somecases, these ontologies may be interrogated to identify alternativeactivities or places of interest (e.g., other exemplars in the samecategory as the next geolocation) to include in fields in templates orotherwise indicate in messages generated for users to propose saferalternatives.

For example, some embodiments may rank alternatives according togeolocation-pathogen-risk scores of those alternatives and present thosehaving greater than a threshold ranking. In some cases, the ranking mayalso be based on travel time or distance, for instance, withrisk-weighted distance or travel time, and again those options above athreshold ranking may be presented to the user via the nativeapplication 58, in some cases with a link to navigation directions or awebsite or other profile of the alternative activity or place ofinterest, like a timeline of the places geolocation-pathogen-risk score.

In some cases, the templates may include fields about the user, likeage, health status, comorbidities, goals or risk preferences enteredinto the native application 58, compliance rates, or the like. In somecases, this information may be stored exclusively client-side, in memoryof the native application 58, and templates may be populated in part orentirely on the mobile computing device 14, by the native application 58by querying values from memory to populate these fields. In some cases,some fields with less sensitive information may be populated by theserver system 12 before a partially populated template is sent to themobile computing device 14. For example, a template may state “please becareful. Someone with {insert query result for highest-rankingcomorbidity of user} should be particularly careful about visiting thisplace due to risk of infection,” with the text in brackets beinginserted client-side, before the fully populated template is presentedas a text warning to the user. Or in some cases, users may consent tohave their information stored in encrypted format, with otherwiseanonymous identifiers, server-side, and fields may be populated intemplates before those templates are sent to the mobile computing device14.

In some cases, templates or other messages may be formed based uponinformation drawn from a social graph of the user. Some people may wantto be particularly careful about their risk of giving a particularpathogen to someone in their social graph or within some thresholdnumber of degrees of connection in their social graph. In some cases,the social graphs may again be stored client-side and operations thereonmay be performed client-side, for example, to populate templates or toselect among candidate natural language text for messages. (It should beemphasized that natural language text may be embedded in, or referencedby, structured text while still qualifying itself as natural languagetext.) For example, some embodiments may recursively traverse a socialgraph of the user to some threshold depth and determine whether anyother users within that range have greater than a threshold risk foreach of a plurality of pathogens, like risk of death, risk ofhospitalization, or the like.

Upon determining that some users within the threshold range ofconnections in the social graph present such risk, in response, someembodiments may populate a template to indicate something like “morethan three people you know (or that are friends with people you know)are particularly vulnerable to pathogen X, and the risk of infection ofpathogen X at the next place you plan to visit is particularly high andtrending upward.” In some cases, users may be reminded of risk ofparticular people in their social graph, like family members that arevulnerable, for instance, with fields populated with client-sideoperations performed by the mobile computing device 14 executing thenative application 58, to prevent the need to store sensitive familyinformation server-side, though embodiments are also consistent withthat server-side approach when appropriate consent is obtained andanonymization is applied.

In some embodiments, the natural-language-text generation model maygenerate text expressions of less than 50 or 500 words to providerelatively concise warnings or other advice. In some embodiments, otherforms of content may also be selected or otherwise generated with thedescribed techniques, like images or audio conveying the described typesof information. Examples of information presented the user may includethe following: advise the user of pathogen risk associated with ageolocation; advise the user of pathogen risk associated with a sequenceof geolocations visited, or to be visited, by the user; advise the userof alternative geolocations with lower pathogen risk in a same categoryof geolocation as the next geolocation; advise the user ofpathogen-risk-reducing steps to be taken to reduce infection risk;advise the user of an increase in pathogen risk in a geographic regionand steps to be taken to reduce infection risk; advise the user to getvaccinated; advise the user of an activity they could engage in uponbeing vaccinated; advise the user to wear a mask; advise the user toshelter in place; advise the user that their pattern of behaviorpresents less than a threshold risk of infection; and advise the userthat their pattern of behavior presents greater than the threshold riskof infection. Or embodiments may include at least 1, 2, 3, 4, 5, 6 ormore or fewer of these, in any permutation.

In some embodiments, the natural-language-text generation model may beoperative to generate natural language text from whole cloth, forinstance with the GPT-3 model, or various other generative models, likegenerative pretraining transformer natural language text models. In somecases, the natural-language-text generation model may be responsive totext sent back in response to messages, from users, like generative orretrieval-based chatbots. Some embodiments may implement models likevarious Seq2Seq models, such as forms of BERT.

Some embodiments may include causing the natural language text of themessage to be presented to the user, as indicated by block 190. In somecases, this may include accessing a third-party service, like FirebaseMessaging Service™ or Apple messaging service™ to determine a networkaddress at which the mobile device is accessible based upon the mobiledevice maintaining an updated record of such network address with thethird-party service, for instance, by operation of the operating system,to reduce application-specific battery consumption of such operationsand avoid having, for example, 20 different applications executing onthe mobile computing device making the same types of updates todifferent services. In some cases, a push notification may be sent tothe native application 58 for presentation on the mobile computingdevice 14 or for conveyance by the mobile computing device 14 to someother computing device, like a wearable computing device, such as asmart watch, or headmounted display, like an augmented reality displayin augmented reality glasses. In some cases, the message may be conveyedas a text message, as an email, or as a post on a social media account.In some cases, the message may be conveyed via audio, for instance, byconverting the message into audio with the text-to-speech model (e.g.,DeepSpeech or Wav2letter) operated by the server system 12 and playingthat audio through a phone call or via a smart speaker of the userhaving installed thereon an instance of the native application 58, likea “skill” in the Amazon Echo™ ecosystem. Similar techniques may be usedto cause messages to be presented by smart appliances, like smarttelevisions, set-top boxes, in-dash automotive computing systems, andthe like. In some cases, messages may be written to a patient record inan electronic medical record system for the doctor to conveyed thepatient.

Some cases, the process 180 may cause messages to be sent to arelatively large number of users, at a relatively large scale, withrelatively little repetition among messages received by anyone user. Forexample, some embodiments may be operative to generate over 1000,10,000, or 100,000 different messages having different content. In somecases, these messages may span more than 5, more than 10, more than 20,or more than 50 different topics, and they may be customized for apopulation of users over a geographic area having scales like thosedescribed above.

In some embodiments, the process 180 may include obtaining feedback oncompliance, as indicated by block 192, and some embodiments may includeupdating the natural anguish text generation module based on thefeedback, as indicated by block 194. In some embodiments, the user mayexpressly provide that feedback, for example by selecting an inputdisplayed along with the message by the native application 58 indicatingwhether they intend to or have complied or relevance of the message totheir current situation. In some cases, the native application 58 maymonitor whether the user traverses a geo-fence indicating that the usercomplied, for instance, that they went to a high-risk geolocation orwent to another alternative lower risk geolocation. In some cases, theseindicia of compliance may be buffered by the native application 58 overtime and aggregate scores (or values with noise injected, like by usingdifferential privacy techniques) may be reported back to the serversystem 12 that do not indicate whether the user in the visited any oneparticular geolocation. For example, an average rate of compliance overa trailing duration of three or five messages may be computed andreported. Or in some cases, these values may be determined server-side.In some cases, compliance may be inferred from the person laterindicating that they contracted a pathogen in input to the nativeapplication 58.

In some embodiments, the feedback may be used to adjust the rangesdescribed above by which message text is probabilistically selected. Insome embodiments, feedback may be used to adjust other parameters of thenatural language text model, for example, in other types of models. Someembodiments may implement a reinforcement learning model to select orotherwise determine messages in a sequence of messages presented to auser over time. In some embodiments, the reinforcement learning modelmay implement a policy and a value function, like a deep reinforcementneural network model with such a policy or value function implemented asa multi-layer network of perceptrons. Such models may be trained withthe techniques described above, for example, with stochastic gradientdescent, using the other approaches described above to increase therobustness of the models. In some embodiments, the value function may beconfigured to determine semantic similarity of messages, for instance,with an encoder model operative to transform messages in naturallanguage into vectors in an embedding space (e.g., with word2vec, orparagraph2fec), where vector distance in the embedding space indicatessemantic similarity. Some embodiments may compute this distance andpenalize or otherwise devalue subsequent messages within thresholdsimilarity distances, e.g., with the value function. In some cases, thethreshold similarity distances may increase as time passes or as anumber of intervening messages have been provided to the user. In somecases, the reinforcement learning model may be a to stochasticreinforcement learning model or a deterministic model. Some embodimentsmay train the model on historical data of the user, and some cases alongwith psychographic or demographic attributes of the user, and in somecases with similar values of a population of other users to selectmessages that tend to increase compliance, reduce infection rates,reduce hospitalization rates, or the like.

Some embodiments may implement AB testing or other types of testing oflarger set of candidate messages. Some embodiments may cause differentmessages to be sent to different users or sample sizes of populations ofdifferent users and determine efficacy of the candidate messages basedupon the feedback. Some embodiments may then adjust thenatural-language-text generation model to increase the likelihood ofthose messages exhibiting greater compliance being presented to users.In some cases, this testing may account for psychographic or demographicattributes of users. For example, users may be organized into cohorts orother groups by clustering users according to psychographic ordemographic attributes. Some embodiments may use another encoding modeltrained to represent users in an another embedding space with 5 or moredimensions based upon 10 or more psychographic or demographic attributesof the users. Some embodiments may execute a density-based clusteringalgorithm (e.g., DB-SCAN) to group users in the embedding space and thensegment groups of users to test different versions of messages on thesimilar topics for the same topic for efficacy in compliance.

Behavior Modification Messaging for Organizations to Reduce PathogenRisk

In some embodiments, the server system 12 includes a finite statemachine 81 that has the states illustrated in state diagram 200 shown inFIG. 6. In some embodiments, depending upon the state of the statemachine, different categories of organizational messaging may beproposed to management to guide pandemic or other pathogen riskmitigation measures among participants of an organization led by suchmanagement or other leaders. Such organizations may includecorporations, not-for-profits, other business entities, armed forces,schools, and the like.

One state machine 81 and corresponding state diagram 200 are shown, butembodiments are consistent with substantially more. For example, eachorganization having a tenant account in a multitenantsoftware-as-a-service implementation of the server system 12 may have acorresponding independently operating state machine 81 with the statesin the diagram 200. In some cases, each facility may have such a statemachine for the organization, where organizations have multiplefacilities in some cases. In some embodiments, there may be a statemachine 81 specific to each shift or department within a facility orfloor of a facility. In some embodiments, there may be one such statemachine for each of multiple pathogens, for each type ofgeolocation-pathogen-risk score, for each shift, for each floor, foreach department, for each facility, for each tenant of the multitenantSaaS application (on some embodiments may run on-premises or in a hybridarchitecture).

In some embodiments, the state machine 81 includes a state 202corresponding to lower risk, which may correspond to thegeolocation-pathogen-risk scores of the various types discussed abovefor the facility or organization at issue. Transitions may be determinedperiodically, like daily, or hourly, or more or less often, orresponsive to events, like a request for an update or new datapotentially affecting state.

The terms lower and higher do not require some absolute reference bywhich lower and higher are measured, but rather reference each other,with things referred to as lower being lower than things referred to ashigher, and vice versa. Thus, use of the term should not be read asindefinite.

In some embodiments, the finite state machine 81 may transition to thelower risk state 202 upon a determination that ageolocation-pathogen-risk score for the facility or collection offacilities at issue (e.g., an average) is less than a threshold (or likethe other threshold determination herein, otherwise satisfies thethreshold, for instance, if it is higher than a threshold, whereincreasing score corresponds to lower risk). In some cases, the finitestate machine may transition to or from the state 202 to or from states204 or 208, depending upon whether risk is trending up or down,respectively.

In some cases, these trends may be determined with a first derivative(which may be an approximation and does not require a differentiablefunction represent the data) of geolocation-risk-scores of facilities orcollections thereof at issue with respect to time. A transition may betriggered upon that first derivative being determined to be higher thanone threshold or lower than another threshold to move to or from states204 and 208. In some embodiments, the finite state machine 81 may alsobe configured to transition between the states 204 and 208, forinstance, when risk scores oscillate over time.

In some cases, the finite state machine 81 further includes a state 206corresponding to a higher geolocation pathogen risk of a facility orcollection of facilities at issue. In some cases, the finite statemachine 81 may transition to or from this state 206 or to or from states204 or 208 upon determining that the geolocation pathogen risk for thefacility or collection of facilities at issue is greater than athreshold. In some cases, the finite state machine 81 may includeadditional states corresponding to additional gradations of risk (e.g.,three, five, ten, or more), and in some cases, each of these additionalstates may include transitions that pass through the trending up andtrending down states 204 and 208. Some embodiments may further includeadditional states corresponding to a second derivative ofgeolocation-pathogen-risk scores with respect to time, corresponding toscenarios in which risk is accelerating up or down.

In some embodiments, each of the states 204 through 208 may haverespective data and logic by which messaging to participants in anorganization and guidance to leadership of an organization isimplemented consistent with the corresponding state. In some cases,messages may be proposed based upon the process 180 of FIG. 5 discussedabove, using the geolocation-pathogen-risk scores determined with theprocess 140 in FIG. 4 discussed above. In some embodiments, the types ofmessaging and guidance may correspond to the following examples for eachillustrated state in state diagram 200.

After an organization completes profile set up, the state machine mayinitialize to state 202. Suggestions and participant messages may bestructured around safe workforce behavior/practices andemployee/contractor behavior outside of the work place. In state 202,the organization's locations may be operating in a low risk virusenvironment, e.g., based on the reporting district'geolocation-pathogen-risk scores or those for the facilities. Anadministrator's computing device may receive 1 to 2 workforce safetymessages daily. Further, the organization may develop its own workforcesafety procedures, scenario appropriate ones of which may be accessedvia the user interface described below with reference to FIG. 7. Theremay be thousands or more messages available in the system as candidatesto select among.

Transition to state 204 may occur if the level of risk in a reportingdistrict where a facility operates rises during a pandemic or if thefacility's score increases. An administrator and location leadership maybe informed of this risk and the related messaging platform change. In arising risk environment, some embodiments may activate differentmessaging content. This content may be designed to inform theadministrator and location leadership (through messages to, andpresented by, their computing devices) of the nature of the increasedrisk and provide suggestions for lowering company and workforce risklevels. If risk levels continue to rise in the facility, the messagingcontent may change to display the types of actions leadership shouldconsider to reduce the risk of participant infection and death.

If the level of risk escalates to a critical stage, e.g., whereshelter-in-place is mandatory, a transition to state 206 may activateother content. In this state, some embodiments deliver messaging tosupport the facility's leadership and participants and their compliancewith federal, state, or local restrictions. The administrator andleadership may select messages that indicate that all movement are“essential only” and increase the likelihood that participants are awareof and compliant with government mandates and reduce the risk ofpathogen exposure.

In a reducing risk environment, the system may transition to state 208and active other content. This content may be designed to inform theadministrator and leadership of the nature of the decreased risk andprovide suggestions for continuing to lowering risk levels. If risklevels continue to fall, the messaging content will change to displaythe new types of actions the leadership or other participants may taketo further reduce or maintain a safe and healthy organization.

In some embodiments, execution of the finite state machine 81 may causethe server system 12, for instance in cooperation with the controller74, to cause computing devices of leadership of an organization topresent a user interface like interface 220 shown in FIG. 7. In someembodiments, the user interface 220 like the other user interfacesdescribed herein, may be presented in a web browser or in the nativeapplication 58, in some cases upon a corresponding user authenticatingthemselves as a member of leadership to the server system 12 through anidentity management system. In some embodiments, the user interface 220includes a facility-risk heat map 222 having a map extent shown withinthe illustrated rectangle and including various facilities 224 depictedtherein. This map may support panning, zooming, and bounding-box-querieslike those examples discussed above, which may also entail a mapinterface like that shown. In some embodiments, visual attributes ofthose facilities 224 may be modulated to indicate geolocation pathogenrisk, for example color, line weight, animated movements, and the like.In some embodiments, each of the facilities illustrated 224 maycorrespond to a region of a display screen that when selected by theuser, causing an event (like an on-touch event, a touch-release event,an on-click event, or the like) to be passed to an event handler thatcauses the user interface 222 update to display additional informationabout the respective facility, for example, upon querying server system12 for such information. Examples include breakdowns by risk pod,trendlines for geolocation-pathogen-risk scores, aggregate statisticsabout vulnerability of visitors to the respective facility to pathogenat issue, and the like.

In some embodiments, the user interface 220 includes proposed naturallanguage text 226 specific to each facility and each risk pod of eachwas facility. In some embodiments, the proposed text may be determinedwith process 180 described above. In some embodiments, there may bemultiple options of proposed text. Similar UI elements may displaymessages to leadership that are not editable. In some embodiments, eachunit of proposed text may be in a text input box that supports editingor rewriting. A rewrite or supply of new text from a user in leadershipis considered an edit in this example. In some embodiments, the userinterface 220 further includes inputs by which the message may be sentor with which the message may be placed into a state that supportsediting, as indicated by buttons 228 and 230 respectively. Sending amessage with selection of button 228 may trigger any of the variousmodes of conveying messages discussed above with reference to step 190of block 180, among the other examples above.

Privacy-Safe Movement Transaction Processing to Assess Pandemic Risk

Some embodiments may implement a privacy preserving approach togathering data about people's movements among geographic places, whichin some cases may not reveal to server-side hardware (e.g., serversystem 12, which may include one or more servers) the identity of thosepeople or, and some cases, which movements at different times aremovements by the same person to impede attempts to deanonymize databased upon patterns of movements unique to individuals.

Some embodiments include obtaining movement transactions of a populationof users, for instance in accordance with the techniques describedabove, by which native applications 58 executing on user's mobilecomputing devices 14 sense their geolocation and provide correspondinginformation to server system 12 that obtains the information. In somecases, the native application may be operative to generate movementtransactions, each movement transaction including a starting geographicposition (e.g., lat-long coordinates or place-of-interest, geographicregion, or other geolocation identifier), an ending geographic position,and a datestamp, such as a timestamp with varying levels of granularity,like specific to the minute, hour, day, or week, or more or lessgranular, in some case for both starting and ending positions, or insome cases for just one or an average thereof.

In some embodiments, movement transactions may begin and end with thedetection of dwells at geographic locations, for instance thosegeolocations including the geographic positions, like places of interestor geographic regions. In some embodiments, the native application 58,or the geolocation framework 60, may be configured to detect dwells and,in response, emit an event or call a previously-registered callbackfunction that causes a new movement transaction to be created by thenative application 58, for instance, indicating a movement from apreviously detected well to a new dwell. In some embodiments, dwells maybe detected responsive to a determination that the geolocation of themobile computing device 14 has remained within a geographic area, likewithin a geo-fence, for more than a threshold amount of time, like morethan five minutes, more than 10 minutes, or more than an hour.

In some embodiments, the movement transactions may be formatted orotherwise transformed from source data in a way that impedes attempts todeanonymize collections of movement transactions through statisticalanalysis for patterns unique to individuals. In some embodiments,movement transactions may not include personally identifiableinformation about users, global unique identifiers within a namespace ofthe server system 12 by which different users are distinguished withfrom one another, even if pseudonymously, or the like. In someembodiments, movement transactions are encoded in a less granular formatthan that with which data is sensed by the mobile computing device 14.For example, dwells detected at the level of an individual room or floorof a building may be encoded in the movement transaction as indicatingthe corresponding place of interest or geographic region, withoutidentifying the individual room or floor of the building. In someembodiments, noise may be added to geolocation of starting or endingpositions of dwells, for example, by randomly selecting a distance andan angle and offsetting the geolocation of starting and endingpositions, or date stamps may be adjusted by adding or subtractingrandom offsets. In some embodiments, these random values may be selectedfrom a normal distribution, such that aggregations of such values mayproduce population statistics of measures of central tendency that areunaffected by the noise, while individual movement transactions provideunreliable information about that individual movement.

In some embodiments, the movement transactions are reported to theserver system 12 at the time a movement transaction concludes, or insome embodiments, native applications 58 may buffer such movementtransactions, for example, for an hour, day, week, or longer or shorterduration, before a batch is sent to the server system 12. In someembodiments, the movement transactions may be conveyed to the serversystem 12 in a manner that either does not identify the mobile computingdevice or corresponding user undergoing those movements to the serversystem 12 or does not leave a persistent record at the server system 12by which such information can be retrieved later. In some cases, theinformation may be conveyed over a network 26 in a protocol, like theInternet protocol, that includes a source network address of the sendingcomputing device 14 in a header of an Internet protocol packet receivedby the system 12 when conveying movement transactions as a payload ofthat packet. In some embodiments, the server system 12 may immediately(e.g., within a day, minute, or 50 ms of receipt) delete the sendernetwork address from such received packets. Similar techniques may beapplied to session identifiers in some cases at other layers of aprotocol stack, for example upon determining that a session hascompleted or more than a threshold amount of time has elapsed since asession began or was last active.

In some embodiments, movement transactions may be conveyed to the serversystem 12 from sending mobile computing devices 14 in a way thatprevents the server system 12 from having access to the network addressor other device identifier of mobile computing devices 14 by whichmobile computing devices 14 (or users, or instances of nativeapplication 48) can be uniquely (or specified to some granularity, likeless than 10% of users, less than 1% of users, or less than 0.0001% ofusers) distinguished from other mobile computing devices of a populationof users. For example, some embodiments may relay movement transactionsvia the Tor network. In another example, a decentralized routingprotocol may be implemented among peer relays implemented by the nativeapplication 58 and a population of users, for example, with one, two,three, four, five or more or fewer hops from a sending mobile computingdevice 14 through a sequence of relaying mobile computing devices 14before a final relaying mobile computing device 14 advances the movementtransactions from the sending mobile computing device 14 to the serversystem 12.

In some embodiments, the sending mobile computing device 14 may encryptthe movement transactions with a public cryptographic key of the serversystem 12 before sending to a first relaying mobile computing device 14.In some embodiments, such encryption may be implemented with anasymmetric cryptographic protocol, like RSA, El Gamal, lattice-basedencryption, elliptic curve encryption, or the like. In some cases,relaying mobile computing devices 14 may not have access to a plain textversion of the ciphertext containing movement transactions that theyrelay to the server system 12, which may decrypt the ciphertext with aprivate cryptographic key held by the server system 12 in memory and notprovided to the mobile computing devices 14.

In some embodiments, mobile computing devices may select and obtainnetwork addresses of downstream relaying mobile computing devices torelay movement transactions with a variety of techniques. In someembodiments, the mobile computing devices may make the selection in away that does not reveal to the server system 12 which mobile computingdevice was selected or that the selecting mobile computing device hadaccess to a network address of the selected mobile computing devices insome cases. In some embodiments, a distributed hash table may be usedfor addressing among the instances of the native application 58 executedby a population of mobile computing devices 14. Examples includedistributed hash table implementations in Chord and Kademlia. In someembodiments, network addresses, like IP address or identifier suitableto communicate via Firebase Messaging Service™ or the equivalent servicein the Apple ecosystem may be accessed by the mobile computing devices14 for selected relaying mobile computing devices with such a datastructure, without the centralized server system 12 having access toinformation by which it can be determined which peer addresses wereaccessed by an individual mobile computing device 14.

In some embodiments, the server system 12 may send a set of 10, 20, 100,1000, or more or fewer such network addresses to each mobile computingdevice, for example, randomly selected subsets of a population of mobilecomputing devices 14 having the native application 58 installed thereon.In some embodiments, the native applications 58 may store these subsetsof addresses in memory, and randomly select among these subsets todetermine downstream relay nodes in a multi-hop path to the serversystem 12. In some embodiments, each hop may include a hop countappended to the package conveying the movement transactions, with eachrelay incrementing the count, and a final relaying computing device mayroute the information to the server system 12 when it determines the hopcount exceeds a threshold value, like two, three, four or more. In someembodiments, this process is expected to make it difficult or impossibleto deanonymize the network address of the sending mobile computingdevice based upon patterns of movement transactions and the finalrelaying move mobile computing devices network address included in aheader of an Internet protocol packet received by the server system 12.

Some embodiments include obtaining the geolocation pathogen risk scoresof the starting geolocations in the movement transactions received atthe server system 12, for instance by querying records in the geographicinformation system 84, in some cases expediting such queries with thetechniques described above with reference to FIG. 3.

In some embodiments, a relatively large number of such movementtransactions may be processed, like more than 100 million per day orhour, more than 1 billion per day or hour, or more than 10 billion perday or hour, and some embodiments may expedite operations by performinganalyses concurrently, for instance using the above-described techniquesimplemented on compute clusters.

In some embodiments, the movement transactions for a batch (e.g.,corresponding to an hour or day) may be grouped according to endinggeolocation including the ending geographic position of the movementtransactions, and different groups may be assigned to differentcomputing devices in such a compute cluster to concurrently computegeographic-pathogen-risk scores of those respective geolocations, forinstance in accordance with the techniques described above withreference to FIG. 4. To this end, some embodiments include updatinggeographic-pathogen-risk scores of the ending geolocations based upongeographic-pathogen-risk scores of the starting geolocations involve themovement transactions ending at the ending geolocations.

In some embodiments, the updated scores are also based upon rates oftraffic of people at the ending geolocations indicated by the movementtransactions. Rates of traffic may be quantified with a variety ofmetrics including measurements of a number of people inferred to be at ageolocation at a given point of time or windowing time, measurements ofa number of people inferred to be arriving at or leaving from ageolocation of a given point in time or window of time, or a combinationthereof, for example a density-weighted arrival or departure rate metricbased on the product of the number of people inferred to be at ageolocation and the number of people arriving at or leaving thegeolocation at a point in time or window of time. The latter metric maycapture a measure of how much a given person at the geolocationinteracts with other people at the geolocation, as a crowded emergencywaiting room with a long wait time and a lot of people arriving andleaving may exhibit different risk than a turnstile with a lot of peoplepassing therethrough but relatively little dwell time at the turnstile.In some embodiments, individuals' arrival at and then departure from ageolocation may not be correlatable by the server system 12 in virtue ofthe way the movement transactions are anonymized in some embodiments,for instance without a persistent global unique identifier of users ofthe native application 58 being associated with each movementtransaction by which arrivals and departures may be matched.

In some embodiments, rates of traffic at ending geolocations may bedetermined by obtaining a set of movement transactions ending at orleaving from the respective geolocation over a window of time and thensorting those movement transactions according to those times. Someembodiments may then initialize a counter, for example, at zero or basedupon a previously determined count and, then, iterate through the listin order, incrementing the counter with each arrival indicated by anending geographic position at the respective geolocation at issue, anddecrementing the counter with each departure indicated by a startinggeographic position at the respective geolocation at issue. In someembodiments, the counter may indicate an estimate of the number ofpeople at the geolocation at the point in time corresponding to datestamps of movement transactions in the ordered list. In someembodiments, date stamps may be applied to both the start and the end ofmovement transactions by the native application 58 to support suchoperations, or some embodiments may assume a default dwell time and onlyuse arrival datestamps.

In some cases, these date stamps, as noted above, may be encoded in asufficiently course format that it is difficult to reliably correlatethe arrival of a person at a geolocation with the movement transactionto which they correspond, to back out where they started from. In someembodiments, the granularity with which date stamps are reported forstarting or ending geolocations may be modulated based upon the rates oftraffic at those geolocations, for instance. with higher rates oftraffic causing the mobile computing devices 14 to use more granulardate stamped reporting and vice versa, such that geographic places withrelatively little foot traffic may have relatively course date stampsapplied to movement transactions ending at or starting at thosegeolocations, as compared to places with high foot traffic.

In some embodiments, these updated geolocation pathogen risk scores maybe stored and used in the manner described above with reference to FIGS.1 through 7.

Enriching Geographic Information Systems with Pathogen-Risk Enhancing orSuppressing Attributes of Places of Interest

As noted above, in some cases, account holders, like various users,associated with places of interest (e.g., so authorized or merely havingvisited as explained below) may use computing devices 20 (as shown inFIG. 1) to update records in the geographic information system 84 withadditional attributes of places of interest relevant to propensity ofpathogens to be transmitted at the respective geolocations. Examples ofsuch attributes include any permutation of the following or similarattributes: an attribute indicative of an air filtration system of thebuilding; an attribute indicative of a cleaning protocol of thebuilding; an attribute indicative of an ultraviolet light of thebuilding; an attribute indicative circulation of outside air into thebuilding; an attribute indicative of touchless automatic doors of thebuilding; an attribute indicative of humidity of air in the building; anattribute indicative of temperature of air in the building; an attributeindicative of sunlight in the building; an attribute indicative ofpersistence of a pathogen on surfaces in the building; or an attributeindicative of sneeze guards in the building. In some embodiments, thisinformation may be supplied via a web portal or via the nativeapplication 58 described above.

In some embodiments, upon receiving one or more of these attributes, theserver system 12 may update geolocation pathogen risk scores based onthe new information, for example, reducing the amount of risk indicatedby such scores based upon attributes indicating risk-mitigating measurestaken at the places of interest like those discussed above. In someembodiments, this may be a percentage reduction indicated by acoefficient corresponding to each attribute multiplied by the originalscore, some embodiments may subtract an offset corresponding to theattribute, or in some cases, the attributes (or cumulative effectsthereof) may be input features to the above-described machine learningmodels for computing such scores. In some embodiments, the updating maybe performed with the process 140 discussed above with reference to FIG.4. As is the case with the other examples of updating herein, updatingcan include changing an existing value or creating a new copy or versionof the value with the change present.

In some embodiments, a plurality of such attributes of a geolocation maybe received, and some embodiments may determine a cumulative effect ofthose attributes to apply when updating geolocation pathogen riskscores. In some cases, the attributes may combine in nonlinear ways, forexample synergistically, or in some cases counteracting one another. Insome cases, these interaction effects may become quite complicated asadditional attributes are added, for example, increasing with thepossible permutations of the number of attributes, which may increasefactorial a as additional attributes are tracked. In some cases, thenumber of attributes may be greater than 10, 50, 100, or 500.

In some cases, interactions between attributes may be inferred with amachine learning model trained upon historical data stored by the serversystem 12. In some cases, this may be the same model as is used tocompute the above-noted geolocation-pathogen-risk scores in process 140,or it may be a different model, e.g., one downstream of that model inprocess 140, in a pipeline or some other ensemble.

In some embodiments, as a training set, the server system 12 may storeprevious changes in geolocation pathogen risk scores, previous incidentsof infection, missed work, or death at geolocations, along withattributes of those geolocations. Some embodiments may predict a defaultnumber or rate of such adverse events given then existing geolocationpathogen risk scores, for example, with scores that do not account forattributes. Some embodiments may then determine an amount by which thegeolocations over or underperformed these estimates and attribute thosedifferences to the attributes, in some cases, or in some cases includingadditional features. Some embodiments may train a model to predict thesedifferences given attributes based on such historical data. Examples ofsuitable machine learning models include deep (3, 5, 10, or 50 or morelayer) neural networks, regression trees or random forest thereof,linear regressions, and the like. In some cases, these models may betrained or otherwise configured with the techniques described above.

Additionally or alternatively, some embodiments may determine initial orfinal inferred cumulative effects from an interaction matrix, which maybe an n-by-n matrix or n-dimensional matrix, where n is the number ofattributes at issue. In some embodiments, values in this matrix mayindicate the cumulative effect of attributes that indexed to thatlocation.

In some cases, some attributes may be nominal values or binary values,and some attributes may be cardinal or ordinal values. In some cases,each value or range of values in cardinal or ordinal values maycorrespond to a different attribute, e.g., “low, medium, or high outsideairflow” or “0 to 1 watt of UV light per square meter” vs “1 to 3 wattsof UV light per square meter.” Or some embodiments may learn a functionor have hardcoded within the model a function that indicates cumulativeeffects. In some embodiments, different models or interaction matricesmay be maintained for different pathogens and different variantsthereof, as such interactions may vary by pathogen, for instance somemay be subject to fomite transmission, while others are purely aerosol,and different attributes may affect these modalities differently.

In some embodiments, attributes may only be accepted from authenticatedusers determined to be authorized to provide such information by serversystem 12. Examples include those who have previously registered as theentity owning or otherwise controlling a geolocation, like a building,for instance in an organizations account by which facilities are trackedin the manner discussed above with reference to FIGS. 6 and 7. In someembodiments, the general public may be invited to supply attributes,which may produce less reliable reporting. Some embodiments may receivea plurality of different characterizations of an attribute of abuilding, for instance, some indicating the presence of ultravioletlights and others indicating the absence of ultraviolet lights. Someembodiments may reconcile these reports by, for example, determining amajority characterization and selecting the majority characterization asthe attribute. Some embodiments may maintain a reputation system bywhich users are scored according to the historical accuracy of theirreports, and some embodiments may determine a user-accuracy score thatis used to weight user characterizations in such majority votes,selecting an accuracy-weighted majority as the characterization of theattribute to be used.

In some embodiments, upon updating the geographic-pathogen-risk score ofa given geolocation, this change may be used to update othergeographic-pathogen-risk scores of other geolocations, for example,those subject to a co-visitation, as indicated by the above-describedmovement transactions. For example, some embodiments may determine one,two, three, or more degree separations in a movement graph indicated bymovement transactions from the given geolocation subject to the update,and some embodiments may update other geolocationsgeographic-pathogen-risk scores based upon the attribute that wasreported or the resulting change in the given geolocations geographicrisk score. For example, a report of an attribute that tends to reducerisk at a given geolocation may cause the risk score of adjacentgeolocations in a movement graph to be lowered to indicate the reducedrisk of someone contracting a virus while at the given geolocation andthen spreading to others at subsequently visited geolocations.

In some embodiments, these updated geolocation pathogen risk scores maybe stored and used in the manner described above with reference to FIGS.1 through 7.

In some embodiments, the present filing may apply the techniques claimedin the following non-provisional patent applications filed on the sameday as the first non-provisional priority date of this patent filing(and sharing a disclosure with that filing), bearing the followingtitles and attorney docket numbers, with the same inventor and assigneeas that first non-provisional filing, the contents of each of which arehereby incorporated by reference: 062714-0561890 GEOLOCATIONPATHOGEN-RISK ASSESSMENT WITH PANDEMIC-BIO-SURVEILLANCE MULTI PATHOGENSYSTEMS; 062714-0561892 BEHAVIOR-MODIFICATION MESSAGING WITHPANDEMIC-BIO-SURVEILLANCE MULTI PATHOGEN SYSTEMS; 062714-0561893NATURAL-LANGUAGE TEXT GENERATION WITH PANDEMIC-BIO-SURVEILLANCE MULTIPATHOGEN SYSTEMS; 062714-0561894 PRIVACY-PROTECTINGPANDEMIC-BIO-SURVEILLANCE MULTI PATHOGEN SYSTEMS; and 062714-0561896ENRICHING GEOGRAPHIC-INFORMATION SYSTEMS WITH GEOLOCATION ATTRIBUTES TOENHANCE ACCURACY OF PANDEMIC-BIO-SURVEILLANCE MULTI PATHOGEN SYSTEMS.

FIG. 8 is a diagram that illustrates an exemplary computing system 1000in accordance with embodiments of the present technique. Variousportions of systems and methods described herein, may include or beexecuted on one or more computer systems similar to computing system1000. Further, processes and modules described herein may be executed byone or more processing systems similar to that of computing system 1000.

Computing system 1000 may include one or more processors (e.g.,processors 1010 a-1010 n) coupled to system memory 1020, an input/outputI/O device interface 1030, and a network interface 1040 via aninput/output (I/O) interface 1050. A processor may include a singleprocessor or a plurality of processors (e.g., distributed processors). Aprocessor may be any suitable processor capable of executing orotherwise performing instructions. A processor may include a centralprocessing unit (CPU) that carries out program instructions to performthe arithmetical, logical, and input/output operations of computingsystem 1000. A processor may execute code (e.g., processor firmware, aprotocol stack, a database management system, an operating system, or acombination thereof) that creates an execution environment for programinstructions. A processor may include a programmable processor. Aprocessor may include general or special purpose microprocessors. Aprocessor may receive instructions and data from a memory (e.g., systemmemory 1020). Computing system 1000 may be a uni-processor systemincluding one processor (e.g., processor 1010 a), or a multi-processorsystem including any number of suitable processors (e.g., 1010 a-1010n). Multiple processors may be employed to provide for parallel orsequential execution of one or more portions of the techniques describedherein. Processes, such as logic flows, described herein may beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating corresponding output. Processes described herein may beperformed by, and apparatus can also be implemented as, special purposelogic circuitry, e.g., an FPGA (field programmable gate array) or anASIC (application specific integrated circuit). Computing system 1000may include a plurality of computing devices (e.g., distributed computersystems) to implement various processing functions.

I/O device interface 1030 may provide an interface for connection of oneor more I/O devices 1060 to computer system 1000. I/O devices mayinclude devices that receive input (e.g., from a user) or outputinformation (e.g., to a user). I/O devices 1060 may include, forexample, graphical user interface presented on displays (e.g., a cathoderay tube (CRT) or liquid crystal display (LCD) monitor), pointingdevices (e.g., a computer mouse or trackball), keyboards, keypads,touchpads, scanning devices, voice recognition devices, gesturerecognition devices, printers, audio speakers, microphones, cameras, orthe like. I/O devices 1060 may be connected to computer system 1000through a wired or wireless connection. I/O devices 1060 may beconnected to computer system 1000 from a remote location. I/O devices1060 located on remote computer system, for example, may be connected tocomputer system 1000 via a network and network interface 1040.

Network interface 1040 may include a network adapter that provides forconnection of computer system 1000 to a network. Network interface may1040 may facilitate data exchange between computer system 1000 and otherdevices connected to the network. Network interface 1040 may supportwired or wireless communication. The network may include an electroniccommunication network, such as the Internet, a local area network (LAN),a wide area network (WAN), a cellular communications network, or thelike.

System memory 1020 may be configured to store program instructions 1100or data 1110. Program instructions 1100 may be executable by a processor(e.g., one or more of processors 1010 a-1010 n) to implement one or moreembodiments of the present techniques. Instructions 1100 may includemodules of computer program instructions for implementing one or moretechniques described herein with regard to various processing modules.Program instructions may include a computer program (which in certainforms is known as a program, software, software application, script, orcode). A computer program may be written in a programming language,including compiled or interpreted languages, or declarative orprocedural languages. A computer program may include a unit suitable foruse in a computing environment, including as a stand-alone program, amodule, a component, or a subroutine. A computer program may or may notcorrespond to a file in a file system. A program may be stored in aportion of a file that holds other programs or data (e.g., one or morescripts stored in a markup language document), in a single filededicated to the program in question, or in multiple coordinated files(e.g., files that store one or more modules, sub programs, or portionsof code). A computer program may be deployed to be executed on one ormore computer processors located locally at one site or distributedacross multiple remote sites and interconnected by a communicationnetwork.

System memory 1020 may include a tangible program carrier having programinstructions stored thereon. A tangible program carrier may include anon-transitory computer readable storage medium. A non-transitorycomputer readable storage medium may include a machine readable storagedevice, a machine readable storage substrate, a memory device, or anycombination thereof. Non-transitory computer readable storage medium mayinclude non-volatile memory (e.g., flash memory, ROM, PROM, EPROM,EEPROM memory), volatile memory (e.g., random access memory (RAM),static random access memory (SRAM), synchronous dynamic RAM (SDRAM)),bulk storage memory (e.g., CD-ROM and/or DVD-ROM, hard-drives), or thelike. System memory 1020 may include a non-transitory computer readablestorage medium that may have program instructions stored thereon thatare executable by a computer processor (e.g., one or more of processors1010 a-1010 n) to cause the subject matter and the functional operationsdescribed herein. A memory (e.g., system memory 1020) may include asingle memory device and/or a plurality of memory devices (e.g.,distributed memory devices). Instructions or other program code toprovide the functionality described herein may be stored on a tangible,non-transitory computer readable media. In some cases, the entire set ofinstructions may be stored concurrently on the media, or in some cases,different parts of the instructions may be stored on the same media atdifferent times.

I/O interface 1050 may be configured to coordinate I/O traffic betweenprocessors 1010 a-101On, system memory 1020, network interface 1040, I/Odevices 1060, and/or other peripheral devices. I/O interface 1050 mayperform protocol, timing, or other data transformations to convert datasignals from one component (e.g., system memory 1020) into a formatsuitable for use by another component (e.g., processors 1010 a-101On).I/O interface 1050 may include support for devices attached throughvarious types of peripheral buses, such as a variant of the PeripheralComponent Interconnect (PCI) bus standard or the Universal Serial Bus(USB) standard.

Embodiments of the techniques described herein may be implemented usinga single instance of computer system 1000 or multiple computer systems1000 configured to host different portions or instances of embodiments.Multiple computer systems 1000 may provide for parallel or sequentialprocessing/execution of one or more portions of the techniques describedherein.

Those skilled in the art will appreciate that computer system 1000 ismerely illustrative and is not intended to limit the scope of thetechniques described herein. Computer system 1000 may include anycombination of devices or software that may perform or otherwise providefor the performance of the techniques described herein. For example,computer system 1000 may include or be a combination of acloud-computing system, a data center, a server rack, a server, avirtual server, a desktop computer, a laptop computer, a tabletcomputer, a server device, a client device, a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a vehicle-mounted computer, or a Global Positioning System(GPS), or the like. Computer system 1000 may also be connected to otherdevices that are not illustrated, or may operate as a stand-alonesystem. In addition, the functionality provided by the illustratedcomponents may in some embodiments be combined in fewer components ordistributed in additional components. Similarly, in some embodiments,the functionality of some of the illustrated components may not beprovided or other additional functionality may be available.

Those skilled in the art will also appreciate that while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them may be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with the illustrated computer system via inter-computercommunication. Some or all of the system components or data structuresmay also be stored (e.g., as instructions or structured data) on acomputer-accessible medium or a portable article to be read by anappropriate drive, various examples of which are described above. Insome embodiments, instructions stored on a computer-accessible mediumseparate from computer system 1000 may be transmitted to computer system1000 via transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as a network or a wireless link. Various embodiments may furtherinclude receiving, sending, or storing instructions or data implementedin accordance with the foregoing description upon a computer-accessiblemedium. Accordingly, the present techniques may be practiced with othercomputer system configurations.

In block diagrams, illustrated components are depicted as discretefunctional blocks, but embodiments are not limited to systems in whichthe functionality described herein is organized as illustrated. Thefunctionality provided by each of the components may be provided bysoftware or hardware modules that are differently organized than ispresently depicted, for example such software or hardware may beintermingled, conjoined, replicated, broken up, distributed (e.g. withina data center or geographically), or otherwise differently organized.The functionality described herein may be provided by one or moreprocessors of one or more computers executing code stored on a tangible,non-transitory, machine readable medium. In some cases, notwithstandinguse of the singular term “medium,” the instructions may be distributedon different storage devices associated with different computingdevices, for instance, with each computing device having a differentsubset of the instructions, an implementation consistent with usage ofthe singular term “medium” herein. In some cases, third party contentdelivery networks may host some or all of the information conveyed overnetworks, in which case, to the extent information (e.g., content) issaid to be supplied or otherwise provided, the information may providedby sending instructions to retrieve that information from a contentdelivery network.

The reader should appreciate that the present application describesseveral independently useful techniques. Rather than separating thosetechniques into multiple isolated patent applications, applicants havegrouped these techniques into a single document because their relatedsubject matter lends itself to economies in the application process. Butthe distinct advantages and aspects of such techniques should not beconflated. In some cases, embodiments address all of the deficienciesnoted herein, but it should be understood that the techniques areindependently useful, and some embodiments address only a subset of suchproblems or offer other, unmentioned benefits that will be apparent tothose of skill in the art reviewing the present disclosure. Due to costsconstraints, some techniques disclosed herein may not be presentlyclaimed and may be claimed in later filings, such as continuationapplications or by amending the present claims. Similarly, due to spaceconstraints, neither the Abstract nor the Summary of the Inventionsections of the present document should be taken as containing acomprehensive listing of all such techniques or all aspects of suchtechniques.

It should be understood that the description and the drawings are notintended to limit the present techniques to the particular formdisclosed, but to the contrary, the intention is to cover allmodifications, equivalents, and alternatives falling within the spiritand scope of the present techniques as defined by the appended claims.Further modifications and alternative embodiments of various aspects ofthe techniques will be apparent to those skilled in the art in view ofthis description. Accordingly, this description and the drawings are tobe construed as illustrative only and are for the purpose of teachingthose skilled in the art the general manner of carrying out the presenttechniques. It is to be understood that the forms of the presenttechniques shown and described herein are to be taken as examples ofembodiments. Elements and materials may be substituted for thoseillustrated and described herein, parts and processes may be reversed oromitted, and certain features of the present techniques may be utilizedindependently, all as would be apparent to one skilled in the art afterhaving the benefit of this description of the present techniques.Changes may be made in the elements described herein without departingfrom the spirit and scope of the present techniques as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include”,“including”, and “includes” and the like mean including, but not limitedto. As used throughout this application, the singular forms “a,” “an,”and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms describing conditionalrelationships, e.g., “in response to X, Y,” “upon X, Y,”, “if X, Y,”“when X, Y,” and the like, encompass causal relationships in which theantecedent is a necessary causal condition, the antecedent is asufficient causal condition, or the antecedent is a contributory causalcondition of the consequent, e.g., “state X occurs upon condition Yobtaining” is generic to “X occurs solely upon Y” and “X occurs upon Yand Z.” Such conditional relationships are not limited to consequencesthat instantly follow the antecedent obtaining, as some consequences maybe delayed, and in conditional statements, antecedents are connected totheir consequents, e.g., the antecedent is relevant to the likelihood ofthe consequent occurring. Statements in which a plurality of attributesor functions are mapped to a plurality of objects (e.g., one or moreprocessors performing steps A, B, C, and D) encompasses both all suchattributes or functions being mapped to all such objects and subsets ofthe attributes or functions being mapped to subsets of the attributes orfunctions (e.g., both all processors each performing steps A-D, and acase in which processor 1 performs step A, processor 2 performs step Band part of step C, and processor 3 performs part of step C and step D),unless otherwise indicated. Similarly, reference to “a computer system”performing step A and “the computer system” performing step B caninclude the same computing device within the computer system performingboth steps or different computing devices within the computer systemperforming steps A and B. Further, unless otherwise indicated,statements that one value or action is “based on” another condition orvalue encompass both instances in which the condition or value is thesole factor and instances in which the condition or value is one factoramong a plurality of factors. Unless otherwise indicated, statementsthat “each” instance of some collection have some property should not beread to exclude cases where some otherwise identical or similar membersof a larger collection do not have the property, i.e., each does notnecessarily mean each and every. Limitations as to sequence of recitedsteps should not be read into the claims unless explicitly specified,e.g., with explicit language like “after performing X, performing Y,” incontrast to statements that might be improperly argued to imply sequencelimitations, like “performing X on items, performing Y on the X′editems,” used for purposes of making claims more readable rather thanspecifying sequence. Statements referring to “at least Z of A, B, andC,” and the like (e.g., “at least Z of A, B, or C”), refer to at least Zof the listed categories (A, B, and C) and do not require at least Zunits in each category. Unless specifically stated otherwise, asapparent from the discussion, it is appreciated that throughout thisspecification discussions utilizing terms such as “processing,”“computing,” “calculating,” “determining” or the like refer to actionsor processes of a specific apparatus, such as a special purpose computeror a similar special purpose electronic processing/computing device.Features described with reference to geometric constructs, like“parallel,” “perpendicular/orthogonal,” “square”, “cylindrical,” and thelike, should be construed as encompassing items that substantiallyembody the properties of the geometric construct, e.g., reference to“parallel” surfaces encompasses substantially parallel surfaces. Thepermitted range of deviation from Platonic ideals of these geometricconstructs is to be determined with reference to ranges in thespecification, and where such ranges are not stated, with reference toindustry norms in the field of use, and where such ranges are notdefined, with reference to industry norms in the field of manufacturingof the designated feature, and where such ranges are not defined,features substantially embodying a geometric construct should beconstrued to include those features within 15% of the definingattributes of that geometric construct. The terms “first”, “second”,“third,” “given” and so on, if used in the claims, are used todistinguish or otherwise identify, and not to show a sequential ornumerical limitation. As is the case in ordinary usage in the field,data structures and formats described with reference to uses salient toa human need not be presented in a human-intelligible format toconstitute the described data structure or format, e.g., text need notbe rendered or even encoded in Unicode or ASCII to constitute text;images, maps, and data-visualizations need not be displayed or decodedto constitute images, maps, and data-visualizations, respectively;speech, music, and other audio need not be emitted through a speaker ordecoded to constitute speech, music, or other audio, respectively.Computer implemented instructions, commands, and the like are notlimited to executable code and can be implemented in the form of datathat causes functionality to be invoked, e.g., in the form of argumentsof a function or API call. To the extent bespoke noun phrases (and othercoined terms) are used in the claims and lack a self-evidentconstruction, the definition of such phrases may be recited in the claimitself, in which case, the use of such bespoke noun phrases should notbe taken as invitation to impart additional limitations by looking tothe specification or extrinsic evidence.

In this patent, to the extent any U.S. patents, U.S. patentapplications, or other materials (e.g., articles) have been incorporatedby reference, the text of such materials is only incorporated byreference to the extent that no conflict exists between such materialand the statements and drawings set forth herein. In the event of suchconflict, the text of the present document governs, and terms in thisdocument should not be given a narrower reading in virtue of the way inwhich those terms are used in other materials incorporated by reference.

The present techniques will be better understood with reference to thefollowing enumerated embodiments:

-   1. A tangible, non-transitory, machine-readable medium storing    instructions that, when executed by one or more processors,    effectuate operations comprising: obtaining, with a computer system,    a user profile of a user; obtaining, with the computer system, a    history of geolocations visited by the user; determining, with the    computer system, based on the history of geolocations,    geolocation-pathogen-risk scores corresponding to the geolocations    visited by the user; determining, with the computer system, a    personal-pathogen-risk score of the user based on the user profile    and the geolocation-pathogen-risk scores corresponding to the    geolocations visited by the user; and storing, with the computer    system, the personal-pathogen-risk score in memory.-   2. The medium of embodiment 1, wherein the personal-pathogen-risk    score of the user is determined based on: rates of infection or    death from a pathogen in the geolocations visited by the user;    medical issues including whether or not the user has received a    vaccination, physiological attributes, and demographic attributes of    the user; movement and behavior patterns of the user; and    responsiveness of the user to dynamic behavior modification    messaging and dynamic risk scoring.-   3. The medium of any one of embodiments 1-2, wherein the    personal-pathogen-risk score of the user is determined based on:    personal-pathogen-risk scores of other users adjacent the user in a    social graph.-   4. The medium of any one of embodiments 1-3, wherein: the    geolocation-pathogen-risk scores are indexed by time or date and are    selected to correspond to a time or date that the user was at the    corresponding geolocation.-   5. The medium of any one of embodiments 1-4, wherein: the computer    system comprises a native application installed on a mobile    computing device of the user and a remote server system with which    the native application is configured to communicate; and the history    of geolocations visited by the user is obtained by the native    application from a geolocation sensor of the mobile computing    device.-   6. The medium of embodiment 5, wherein: determining the    personal-pathogen-risk score is performed by the native application.-   7. The medium of embodiment 5, wherein: determining the    personal-pathogen-risk score is performed by the server system    without the server system having access to an identity of the user.-   8. The medium of embodiment 5, wherein: the native application is    configured to predict a change in the personal-pathogen-risk score    of the user that will occur if the user visits a designated    geolocation in the future.-   9. The medium of any one of embodiments 1-8, wherein: at least part    of the profile is obtained from an electronic medical records    system; and the operations comprise causing a user interface to    present the personal-pathogen-risk score or a value indicative    thereof to a healthcare worker.-   10. The medium of any one of embodiments 1-9, wherein: determining a    personal-pathogen-risk score of the user comprises determining a    plurality of variant-specific personal-pathogen-risk scores of the    user, each corresponding to a different variant of the pathogen.-   11. The medium of any one of embodiments 1-10, wherein: at least    some of the geolocation-pathogen-risk scores are scores specific to    individual buildings and open spaces, such that different buildings    and open spaces in the same geographic area have different    geolocation-pathogen-risk scores.-   12. The medium of any one of embodiments 1-11, wherein: at least    some of the geolocation-pathogen-risk scores are scores specific to    individual floors of individual buildings at designed times of day    for designated variants of the pathogen; and the    personal-pathogen-risk score of the user is based on dwell duration    on at least some of the floors of the user.-   13. The medium of any one of embodiments 1-12, wherein the    operations comprise: determining that one of the    geolocation-pathogen-risk scores has changed for a time at which the    user visited the corresponding geolocation and, in response,    updating the personal-pathogen-risk score of the user.-   14. The medium of any one of embodiments 1-13, wherein the    operations comprise: obtaining a value indicative of responsiveness    of the user to behavior-modification messaging; and modifying a    given one of the geolocation-pathogen-risk scores corresponding to    the geolocations visited by the user based on the value indicative    of responsiveness of the user to behavior-modification messaging.-   15. The medium of any one of embodiments 1-14, wherein: the    personal-pathogen-risk score is an estimate of a likelihood that the    user will experience medical conditions, hospitalization, or death    as a result of being infected by the pathogen; the user has a    different personal-pathogen-risk score than other users; the    personal-pathogen-risk score is indicative of both likelihood of    being infected and severity of consequences upon infection; and the    user has different personal-pathogen-risk scores for different    corresponding pathogens. The personal-pathogen-risk score allows a    user to increase any score based on their overall risk preference.-   16. The medium of any one of embodiments 1-15, wherein: the    personal-pathogen-risk score is based on both underlying medical    conditions of the user and respective confidence values indicative    of strength of evidence that the respective underlying medical    conditions affect risk to the user from the pathogen.-   17. The medium of any one of embodiments 1-16, wherein determining    geolocation-pathogen-risk scores comprises: obtaining the history of    geolocations in the form of time-stamped geographic coordinates;    selecting a unit tile of a geographic grid by determining that a    given one of the geographic coordinates resides in the unit tile;    accessing, based on an identifier of the unit tile, a set of    bounding polygons corresponding to respective places-of-interest in    the unit tile; executing a point-in-polygon algorithm on each of the    bounding polygons to determine a subset of bounding polygons among    the set of bounding polygons in which the a given one of the    geographic coordinates resides; determining that the user visited    one or more places-of-interest corresponding to the subset of    bounding polygons and, in response, determining    geolocation-pathogen-risk scores of the one or more    places-of-interest corresponding to the subset of bounding polygons.-   18. The medium of embodiment 17, wherein: selecting the unit tile of    the geographic grid comprises: truncating at least some    least-significant digits of the geographic coordinates and    determining the identifier of the unit tile from resulting truncated    geographic coordinates.-   19. The medium of embodiment 17, wherein: selecting the unit tile of    the geographic grid comprises converting the given one of the    geographic coordinates into a location on a space filling curve, the    location on the space filling curve being in the unit tile.-   20. The medium of embodiment 19, wherein the space filing curve is a    Hilbert curve.-   21. The medium of any one of embodiments 1-20, wherein: at least    part of the user profile is stored in encrypted form on the mobile    computing device; obtaining the profile of the user comprises:    determining, within an operating system of the mobile computing    device executing on a first set of one or more processors to access    the user profile; and communicating, via processor interrupts, with    a second set of one or more processors, to decrypt the at least part    of the user profile, wherein the second set of one or more    processors do not execute the operating system, a first memory    address space of the first set of one or more processors is    different from a second memory address space of the second set of    one or more processors, and the second memory address space stores    an encryption key by which the at least part of the user profile is    accessed.-   22. The medium of any one of embodiments 1-21, wherein the    operations comprise: obtaining a probabilistic distribution;    randomly selecting a value from the probabilistic distribution;    combing the value with an attribute in the user profile or the    personal-pathogen-risk score of the user; and sending, from the    mobile computing device to a remote server system a result of the    combination.-   23. The medium of any one of embodiments 1-22, wherein: the    personal-pathogen-risk score of the user and personal-pathogen-risk    scores of more than 100,000 other users are computed in real time    with a cluster computing platform; the cluster computing platform is    configured to share datasets upon which the personal-pathogen-risk    scores are based in dynamic memory that is concurrently accessible    to multiple jobs executed by the cluster computing platform.-   24. The medium of embodiment 23, wherein the datasets are stored as    an immutable distributed collection of objects processed by the    cluster computing platform.-   25. The medium of any one of embodiments 1-24, wherein obtaining a    history of geolocations visited by the user comprises determining an    indoor position of the user with an ultrawideband sensor.-   26. The medium of any one of embodiments 1-25, wherein the    operations comprise: determining a risk-mitigation message to the    user based on the user profile and the personal-pathogen-risk score    of the user; and causing the risk-mitigation message to be presented    to the user.-   27. A method comprising: the operations of any one of embodiments    1-26.-   28. A system, comprising: one or more processors; and memory storing    instructions that when executed by the processors cause the    processors to effectuate operations comprising: the operations of    any one of embodiments 1-26.

What is claimed is:
 1. A tangible, non-transitory, machine-readablemedium storing instructions that, when executed by one or moreprocessors, effectuate operations comprising: obtaining, with a computersystem, a user profile of a user; obtaining, with the computer system, ahistory of geolocations visited by the user; determining, with thecomputer system, based on the history of geolocations,geolocation-pathogen-risk scores corresponding to the geolocationsvisited by the user; determining, with the computer system, apersonal-pathogen-risk score of the user based on the user profile andthe geolocation-pathogen-risk scores corresponding to the geolocationsvisited by the user; and storing, with the computer system, thepersonal-pathogen-risk score in memory.
 2. The medium of claim 1,wherein the personal-pathogen-risk score of the user is determined basedon: rates of infection or death from a pathogen in the geolocationsvisited by the user; medical issues, physiological attributes, anddemographic attributes of the user, including their vaccination status;movement and behavior patterns of the user; and responsiveness of theuser to dynamic behavior modification messaging and dynamic risk scoringand the user's personal-risk-index risk escalator.
 3. The medium ofclaim 1, wherein the personal-pathogen-risk score of the user isdetermined based on: personal-pathogen-risk scores of other usersadjacent the user in a social graph.
 4. The medium of claim 1, wherein:the geolocation-pathogen-risk scores are indexed by time or date and areselected to correspond to a time or date that the user was at thecorresponding geolocation; and the ability of a user to select past,current, or future dates for a geolocation to seegeolocation-pathogen-risk scores.
 5. The medium of claim 1, wherein: thecomputer system comprises a native application installed on a mobilecomputing device of the user and a remote server system with which thenative application is configured to communicate; and the history ofgeolocations visited by the user is obtained by the native applicationfrom a geolocation sensor of the mobile computing device.
 6. The mediumof claim 5, wherein: determining the personal-pathogen-risk score isperformed by the native application.
 7. The medium of claim 5, wherein:determining the personal-pathogen-risk score is performed by the serversystem without the server system having access to an identity of theuser.
 8. The medium of claim 5, wherein: the native application isconfigured to predict a change in the personal-pathogen-risk score ofthe user that will occur if the user visits a designated geolocation inthe future, including the ability to deliver a newpersonal-pathogen-risk score for a pathogen not present in the user'scurrent home city, state or country.
 9. The medium of claim 1, wherein:at least part of the profile is obtained from or resides in a nativeformat within an electronic medical records system; and the operationscomprise causing a user interface to present the personal-pathogen-riskscore or a value indicative thereof to a healthcare worker.
 10. Themedium of claim 1, wherein: determining a personal-pathogen-risk scoreof the user comprises determining a plurality of variant-specificpersonal-pathogen-risk scores of the user, each corresponding to adifferent variant of the pathogen.
 11. The medium of claim 1, wherein:at least some of the geolocation-pathogen-risk scores are scoresspecific to individual buildings and open spaces, such that differentbuildings and open spaces in the same geographic area have differentgeolocation-pathogen-risk scores.
 12. The medium of claim 1, wherein: atleast some of the geolocation-pathogen-risk scores are scores specificto individual floors of individual buildings at designed times of dayfor designated variants of the pathogen; and the personal-pathogen-riskscore of the user is based on dwell duration on at least some of thefloors of the user.
 13. The medium of claim 1, wherein the operationscomprise: determining that one of the geolocation-pathogen-risk scoreshas changed for a time at which the user visited the correspondinggeolocation and, in response, updating the personal-pathogen-risk scoreof the user.
 14. The medium of claim 1, wherein the operations comprise:obtaining a value indicative of responsiveness of the user tobehavior-modification messaging; and modifying a given one of thegeolocation-pathogen-risk scores corresponding to the geolocationsvisited by the user based on the value indicative of responsiveness ofthe user to behavior-modification messaging.
 15. The medium of claim 1,wherein: the personal-pathogen-risk score is an estimate of a likelihoodthat the user will experience medical conditions, hospitalization, ordeath as a result of being infected by the pathogen; the user has adifferent personal-pathogen-risk score than other users; thepersonal-pathogen-risk score is indicative of both likelihood of beinginfected and severity of consequences upon infection; the user hasdifferent personal-pathogen-risk scores for different correspondingpathogens; and the personal-pathogen-risk score changes as the user agesand experiences underlying change to their medical and behavioralconditions.
 16. The medium of claim 1, wherein: thepersonal-pathogen-risk score is based on both underlying medicalconditions of the user and respective confidence values indicative ofstrength of evidence that the respective underlying medical conditionsaffect risk to the user from the pathogen.
 17. The medium of claim 1,wherein determining geolocation-pathogen-risk scores comprises:obtaining the history of geolocations in the form of time-stampedgeographic coordinates; selecting a unit tile of a geographic grid bydetermining that a given one of the geographic coordinates resides inthe unit tile; accessing, based on an identifier of the unit tile, a setof bounding polygons corresponding to respective places-of-interest inthe unit tile; executing a point-in-polygon algorithm on each of thebounding polygons to determine a subset of bounding polygons among theset of bounding polygons in which the a given one of the geographiccoordinates resides; determining that the user visited one or moreplaces-of-interest corresponding to the subset of bounding polygons and,in response, determining geolocation-pathogen-risk scores of the one ormore places-of-interest corresponding to the subset of boundingpolygons.
 18. The medium of claims 17, wherein: selecting the unit tileof the geographic grid comprises: truncating at least someleast-significant digits of the geographic coordinates and determiningthe identifier of the unit tile from resulting truncated geographiccoordinates.
 19. The medium of claims 17, wherein: selecting the unittile of the geographic grid comprises converting the given one of thegeographic coordinates into a location on a space filling curve, thelocation on the space filling curve being in the unit tile.
 20. Themedium of claim 19, wherein the space filing curve is a Hilbert curve.21. The medium of claim 1, wherein: at least part of the user profile isstored in encrypted form on the mobile computing device; obtaining theprofile of the user comprises: determining, within an operating systemof a mobile computing device executing on a first set of one or moreprocessors to access the user profile; and communicating, via processorinterrupts, with a second set of one or more processors, to decrypt theat least part of the user profile, wherein the second set of one or moreprocessors do not execute the operating system, a first memory addressspace of the first set of one or more processors is different from asecond memory address space of the second set of one or more processors,and the second memory address space stores an encryption key by whichthe at least part of the user profile is accessed.
 22. The medium ofclaim 1, wherein the operations comprise: obtaining a probabilisticdistribution; randomly selecting a value from the probabilisticdistribution; combing the value with an attribute in the user profile orthe personal-pathogen-risk score of the user; and sending, from a mobilecomputing device to a remote server system, a result of the combination.23. The medium of claim 1, wherein: the personal-pathogen-risk score ofthe user and personal-pathogen-risk scores of more than 100,000 otherusers are computed in real time with a cluster computing platform; thecluster computing platform is configured to share datasets upon whichthe personal-pathogen-risk scores are based in dynamic memory that isconcurrently accessible to multiple jobs executed by the clustercomputing platform.
 24. The medium of claim 23, wherein the datasets arestored as an immutable distributed collection of objects processed bythe cluster computing platform.
 25. The medium of claim 1, whereinobtaining a history of geolocations visited by the user comprisesdetermining an indoor position of the user with an ultrawideband sensor.26. The medium of claim 1, wherein the operations comprise: determininga risk-mitigation message to the user based on the user profile and thepersonal-pathogen-risk score of the user; causing the risk-mitigationmessage to be presented to the user; and changing future risk mitigationmessages based on the extent the user changes or does not changemovement behavior.
 27. The medium of claim 1, wherein the operationscomprise: steps for real-time processing a data stream including thehistory of geolocations.
 28. The medium of claim 1, wherein theoperations comprise: steps for determining the personal-pathogen-riskscore.
 29. The medium of claim 1, wherein: the personal-pathogen-riskscore of the user is determined based on: rates of infection or deathfrom a pathogen in the geolocations visited by the user; medical issues,vaccination status, physiological attributes, and demographic attributesof the user; movement and behavior patterns of the user; responsivenessof the user to dynamic behavior modification messaging and dynamic riskscoring; and personal-pathogen-risk scores of other users adjacent theuser in a social graph; the geolocation-pathogen-risk scores are indexedby time or date and are selected to correspond to a time or date thatthe user visited the corresponding geolocation; the computer systemcomprises a native application installed on a mobile computing device ofthe user and a remote server system with which the native application isconfigured to communicate; the history of geolocations visited by theuser is obtained by the native application from a geolocation sensor ofthe mobile computing device; the native application is configured topredict a change in the personal-pathogen-risk score of the user thatwill occur if the user visits a geolocation designated by a calendar ofthe user; at least part of the profile is obtained from an electronicmedical records system; a the operations comprise causing a userinterface to present the personal-pathogen-risk score or a valueindicative thereof to a healthcare worker; determining apersonal-pathogen-risk score of the user comprises determining aplurality of variant-specific personal-pathogen-risk scores of the user,each corresponding to a different variant of the pathogen; at least someof the geolocation-pathogen-risk scores are scores specific toindividual buildings, such that different buildings in the samegeographic area have different geolocation-pathogen-risk scores; atleast some of the geolocation-pathogen-risk scores are scores specificto individual outdoor spaces or parks, such that different outdoor spaceor parks in the same geographic area have differentgeolocation-pathogen-risk scores; at least some of thegeolocation-pathogen-risk scores are scores specific to individualfloors of individual buildings at designed times of day for designatedvariants of the pathogen; and the personal-pathogen-risk score of theuser is based on dwell duration on at least some of the floors of theuser; the operations comprise determining that one of thegeolocation-pathogen-risk scores has changed for a time at which theuser visited the corresponding geolocation and, in response, updatingthe personal-pathogen-risk score of the user; the operations comprise:obtaining a value indicative of responsiveness of the user tobehavior-modification messaging; and modifying a given one of thegeolocation-pathogen-risk scores corresponding to the geolocationsvisited by the user based on the value indicative of responsiveness ofthe user to behavior-modification messaging the personal-pathogen-riskscore is an estimate of a likelihood that the user will experiencemedical conditions, hospitalization, or death as a result of beinginfected by the pathogen; the user has a differentpersonal-pathogen-risk score than other users; thepersonal-pathogen-risk score is indicative of both likelihood of beinginfected and severity of consequences upon infection; the user hasdifferent personal-pathogen-risk scores for different correspondingpathogens; the personal-pathogen-risk score is based on both underlyingmedical conditions of the user and respective confidence valuesindicative of strength of evidence that the respective underlyingmedical conditions affect risk to the user from the pathogen; whereindetermining geolocation-pathogen-risk scores comprises: obtaining thehistory of geolocations in the form of time-stamped geographiccoordinates; selecting a unit tile of a geographic grid by determiningthat a given one of the geographic coordinates resides in the unit tile;accessing, based on an identifier of the unit tile, a set of boundingpolygons corresponding to respective places-of-interest in the unittile; executing a point-in-polygon algorithm on each of the boundingpolygons to determine a subset of bounding polygons among the set ofbounding polygons in which the a given one of the geographic coordinatesresides; determining that the user visited one or moreplaces-of-interest corresponding to the subset of bounding polygons and,in response, determining geolocation-pathogen-risk scores of the one ormore places-of-interest corresponding to the subset of bounding polygonsselecting the unit tile of the geographic grid comprises either:truncating at least some least-significant digits of the geographiccoordinates and determining the identifier of the unit tile fromresulting truncated geographic coordinates, or converting the given oneof the geographic coordinates into a location on a space filling curve,the location on the space filling curve being in the unit tile, thespace filling curve being a Hilbert curve; at least part of the userprofile is stored in encrypted form on the mobile computing device;obtaining the profile of the user comprises: determining, within anoperating system of the mobile computing device executing on a first setof one or more processors to access the user profile; and communicating,via processor interrupts, with a second set of one or more processors,to decrypt the at least part of the user profile, wherein the second setof one or more processors do not execute the operating system, a firstmemory address space of the first set of one or more processors isdifferent from a second memory address space of the second set of one ormore processors, and the second memory address space stores anencryption key by which the at least part of the user profile isaccessed; the operations comprise: obtaining a probabilisticdistribution; randomly selecting a value from the probabilisticdistribution; combing the value with an attribute in the user profile orthe personal-pathogen-risk score of the user; and sending, from themobile computing device to a remote server system a result of thecombination; the personal-pathogen-risk score of the user andpersonal-pathogen-risk scores of more than 100,000 other users arecomputed in real time with a cluster computing platform; the clustercomputing platform is configured to share datasets upon which thepersonal-pathogen-risk scores are based in dynamic memory that isconcurrently accessible to multiple jobs executed by the clustercomputing platform, wherein the datasets are stored as an immutabledistributed collection of objects processed by the cluster computingplatform; obtaining a history of geolocations visited by the usercomprises determining an indoor position of the user with anultrawideband sensor; and the operations comprise: determining arisk-mitigation message to the user based on the user profile and thepersonal-pathogen-risk score of the user; and causing therisk-mitigation message to be presented to the user.
 30. A method,comprising: obtaining, with a computer system, a user profile of a user;obtaining, with the computer system, a history of geolocations visitedby the user; determining, with the computer system, based on the historyof geolocations, geolocation-pathogen-risk scores corresponding to thegeolocations visited by the user; determining, with the computer system,a personal-pathogen-risk score of the user based on the user profile andthe geolocation-pathogen-risk scores corresponding to the geolocationsvisited by the user; and storing, with the computer system, thepersonal-pathogen-risk score in memory.